From: Luke K. C. L. <lk...@lk...> - 2011-02-01 13:41:34
|
On Tue, Feb 1, 2011 at 1:00 AM, John E. / TDM <td...@td...> wrote: > On 1/31/2011 8:11 AM, Luke Kenneth Casson Leighton wrote: >> On Mon, Jan 31, 2011 at 2:18 PM, John E. / TDM<td...@td...> wrote: >>> Your project, your rules. I'm sorry you find hg so abhorrent. >> john, i can tell you, definitely, it's not "rules", it's sheer >> practicality. python really is a bitch to get working under mingw32 - >> it's why muggins (me) tackled it. compiling git - actually taking >> msys-git and cutting it back drastically (no point reinventing work) - >> is a walk in the park by comparison. > > :S > >> so it's nothing to do with hg, great as it may be, but having >> something like python being _that_ low-level in the dependencies would >> be a complete nightmare. > > Since hg can be (and is, for the Windows build) compiled into a > standalone executable within a built-in Python interpreter, ooo, really!! that would work. that would work extremely well. ... why didn't you mention that earlier, silleee? :) warm regards, l. |
From: Charles W. <cwi...@us...> - 2011-02-01 15:42:51
|
On 2/1/2011 8:41 AM, Luke Kenneth Casson Leighton wrote: > On Tue, Feb 1, 2011 at 1:00 AM, John E. / TDM <td...@td...> wrote: >> On 1/31/2011 8:11 AM, Luke Kenneth Casson Leighton wrote: >>> so it's nothing to do with hg, great as it may be, but having >>> something like python being _that_ low-level in the dependencies would >>> be a complete nightmare. >> >> Since hg can be (and is, for the Windows build) compiled into a >> standalone executable within a built-in Python interpreter, > > ooo, really!! that would work. that would work extremely well. Not really. IIUC, the way hg "includes" a built-in Python interpreter, is you have to HAVE a (port of) python already. The hg files are turned into bytecode, and then the python library which holds the bulk of its code (python.exe is just a thin shell that calls into this library with the cmdline args) is linked into a new exe that includes the python lib and the hg bytecode. So...you STILL have to port python (or use the native w32 python, but then it's really no different that using an ActiveState python + hg .py files, to manipulate files on native windows. It wouldn't really be "integrated" with our offerings at all). Now, I could be wrong but that's my understanding of how the standalone exe its constructed. -- Chuck |
From: Greg C. <chi...@co...> - 2006-02-25 01:36:27
|
On 2006-2-24 23:52 UTC, Earnie Boyd wrote: > Any interest in coverting? Advantages include atomic commits, and real moves and renames instead of CVS's remove-and-add. More here: http://subversion.tigris.org/ Nice, but I never found a compelling reason to switch from CVS. |
From: Aaron W. L. <aar...@aa...> - 2006-02-25 22:45:04
|
Greg Chicares wrote: > Advantages include atomic commits, and real moves and renames > instead of CVS's remove-and-add. More here: > http://subversion.tigris.org/ > Nice, but I never found a compelling reason to switch from CVS. I don't have any vote or opinion, but I've used svn some. In my experience, svn is far better, if anything because it seems "cleaner." It does away with all of the branch and tagging nonsense, which is really great. It's significantly easier to use, has less "gotchas," and has less weird problems. The big thing thats missing is the mythical 'real changesets,' which shows up when doing various merging operations. Of course CVS doesn't have that either. Nonetheless, svn really is just a "better cvs." If you could choose cvs or svn for a new repo, choose svn. For an existing repo, moving to svn would be an improvement, but may not really make anything significant better if there isn't a lot of hardcore use to begin with. As near as I can tell, since mingw's cvs is essentially a parallel mirror repository to sourceware, it really hardly matters. Keeping it cvs would probably make it easier for whomever is doing the merging. However, I suspect sourceware will switch to svn one day... just my two cents. |
From: Wu Y. <ad...@sh...> - 2006-02-26 03:36:21
|
Greg Chicares wrote: > On 2006-2-24 23:52 UTC, Earnie Boyd wrote: > >>Any interest in coverting? > > > Advantages include atomic commits, and real moves and renames > instead of CVS's remove-and-add. More here: > http://subversion.tigris.org/ > Nice, but I never found a compelling reason to switch from CVS. Same with me. Though CVS really is showing age, I am quite reluctant to switch away from it, since there are no `compelling reasons'. And the current toolset works just fine--I use CVSNT on Windows (which have some improvements like real rename and better merging support) and some Vim integration. Best regards, Yongwei |