[crossfire] crossfire source code control systems

[Alex Schultz]

Lalo Martins wrote:
> Sorry if I sound too derisive of hg; it's a great system.  I'm just too
> drunk to be nice.
>
> On Fri, 01 Sep 2006 10:58:38 -0600, Alex Schultz wrote:
>   
>> Well, it would remember the history, which is a step up from cvs, but
>> indeed it doesn't deal with merging nicely with that. Also in theory,
>> could be solved by an extension, because despite merges not following
>> renames, it does track them, and an extension could be written to look
>> at all renamed files, and pull/merge changes from the original files in
>> another repository, not a nice solution, but could be done as an
>> extension in theory.
>>     
>
> That's a good part of the way from writing your own revision control
> system...  yeah it might be possible, but from what I've seen of
> mercurial's extension API, it's not the kind of thing extensions are meant
> for; it would involve quite a bit of dirty monkey-patching.
>   
Well, what I mean, is an extension could implement a separate command
that essentially means "pull&merge changes in renamed files" reasonably
trivially. Also, Mercurial doesn't use a separate extension API for most
things, but one is encouraged to call whatever functions in the
Mercurial code one needs to provided it's safe. I've looked at Mercurial
internals a bit, and making an extension to that would actually rather
simple and fairly clean, but yes, again, it wouldn't really be a nice
solution, but I think would be rather easy to implement.

>> Actually from what I have heard, hg uses hardlinks to save disk space on
>> local branches where available, haven't verified this myself. (It even
>> apparently supports using hardlinks on windows if the windows system is
>> using ntfs). I think the hardlinking is what makes a "hg clone" localy,
>> take 5 seconds, as opposed the "hg init && hg pull" locally taking a
>> minute. (See http://wiki.metalforge.net/doku.php/user:rednaxela:scms for
>> my timing of those two methods of locally coping in hg)
>>     
>
> Up to a few revisions ago, you were encouraged to use hard links in bzr,
> and there are some serious problems with that.  It's a bad hack.
By the sounds of it, bzr used to encourage manually hard linking, which
yes is a bad hack, but the way Mercurial does hard linking internally,
it selectively hard links what files in the history can be safely
hardlinked, and understands perfectly well when it should break the hard
link. I don't really see anything wrong or hackish about the way
Mercurial in particular handles it's hardlinks. I can see "oh, just
hardlink your repository" as hackish for sure, but Mercurial handles
hardlinking internally and does things more intelligently and safely
than just hardlinking the whole repository.


Alex Schultz