[Omake] SVN Commit: OMake Build System (Rev. 10153)

[Nathaniel Gray]

On Mar 4, 2007, at 10:04 AM, Aleksey Nogin wrote:

> On 04.03.2007 08:28, Jason Hickey wrote:
>
>> Module name: OMake Build System
>> Changes by: jyh at cs.caltech.edu (Jason Hickey)
>> Date: 2007-03-04 08:28:53 -0800 (Sun, 04 Mar 2007)
>> Revision: 10153
>> Log message:
>>       I'd like to be able to use GIT for a little while, in the  
>> hope that I
>>       get better branching and merging (to be seen).
>
> GIT, not darcs? As far as I understand, GIT is a fairly narrow hack  
> that
> Linus have created specifically for the purpose of maintaining the
> kernel sources and it is relatively feature-limited.

You might be surprised to learn that I encouraged Jason to use GIT  
rather than darcs.  I'm a big fan of the model darcs uses, but the  
performance issues are real and it seems like it might be better to  
wait until they are solved before spending time building darcs  
workflows.  So I find myself reluctantly advocating GIT.  GIT has at  
least been proven to scale well for very large, very active projects,  
including the kernel, wine, and X.org.  There's also the analysis on  
this page to consider, though they don't mention darcs:

http://keithp.com/blog/Repository_Formats_Matter.html

It's also somewhat interesting to note that there's a DarcsGit  
project that allows one to use darcs on git repositories, though it's  
probably not something to be relied upon.

http://darcs.net/DarcsWiki/DarcsGit

Also on the subject of migration, there's Tailor, which can migrate  
changesets among a variety of SCM tools, including svn, darcs, and git.

http://www.darcs.net/DarcsWiki/Tailor

> Here is the important quote from
> http://changelog.complete.org/posts/528-Whose-Distributed-VCS-Is- 
> The-Most-Distributed.html
> :
>
>> 4. Inividial changesets should be mergeable without bringing  
>> across the whole history
>>
>> Darcs is really the only one that can do this right. I was really  
>> surprised that nobody else could, since it is such a useful and  
>> vital feature for me.
>>
>> Both bzr and git have a cherry-pick mode that simulates this, but  
>> really these commands just get a diff from the specific changeset  
>> requested, then apply the diff as with patch. So you really get a  
>> different changeset committed, which can really complicate your  
>> history later -- AND lead to potential conflicts in future merges.

You might want to look at the responses from git users before  
deciding how much of a problem this is.  For example:

"""
git doesn't do changesets. git tracks file identities at each step.  
The changeset is a derived quantity.

Thus, your #4 works even though you think it won't... You can cherry- 
pick changes, merge later, and have everything work perfectly.  
Seriously. I do this often. The changeset is not replayed, re- 
applied, or anything like that. If the default merge strategy doesn't  
work for you, there are others available. Plus, git-rerere will  
handle some really bizarre cross-merge and rebasing changes for you  
by recording what you did to resolve those changes last time.

Plus, git-cherry-pick by default will record the tree from which you  
picked the changes. The gitk viewer uses that as a link, so you can  
jump to it, etc.

Two holes in git's toolset right now are cloning with limited history  
and handling subprojects. Those are better handled by other tools, alas.
"""

There's also this comment from a monotone developer that summarizes  
my reluctance to commit to darcs at this point:

"""
4) . . . The reason this feature is unique to darcs is that, well, no- 
one knows how to make it actually work -- even darcs (cf. the last  
year+ of traffic on the darcs-traffic list). We're all watching to  
see if the darcs devels solve the problem, but until they do, I don't  
think anyone else wants to get sucked into the situation where there  
are users waiting for you to invent new math that may or may not exist.
"""

In any case, this is just an experiment for Jason, so it's probably  
not too important.  I would really like darcs to work out, since I  
like the "set of partially-ordered patches" concept.  But I suspect  
that git would probably be "good enough" and it has a proven track  
record of scalability, which means that if we *did* decide to use it  
for omake at large there wouldn't be any unnecessary obstacles.

Cheers,
-n8

--
 >>>-- Nathaniel Gray -- Caltech Computer Science ------>
 >>>-- Mojave Project -- http://mojave.cs.caltech.edu -->