[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Gnu-arch-users] Re: bitkeeper vs tla

From: John Meinel
Subject: Re: [Gnu-arch-users] Re: bitkeeper vs tla
Date: Thu, 23 Sep 2004 22:24:26 -0500
User-agent: Mozilla Thunderbird 0.8 (Windows/20040913)

Miles Bader wrote:
Zenaan Harkness <address@hidden> writes:

 * I get the impression from lkml discussion that it has quite strict
   ancestry requirements for merging -- arch on the other hand allows
   some pretty wild & free merge styles, even on trees that have very
   dubious relationships.

Yes. And I think that can be a useful thing, to simplify merges
for the large majority of cases. One of those "layer on arch"
things I'd guess...

Given that bitkeeper achieves this by saying "you can't merge except in
these restricted cases", I'd first check to see what tla does in those
same cases.

If it (by it, I mean star-merge I guess) screws up, then:  Is there
enough meta-info to figure what to do, but star-merge is not smart
enough?  Or is it a case of there being some useful meta-data that arch
should keep but currently isn't.

If tla gets those cases right, _then_ what should you do?  Add optional
restrictions to what the user is allowed to do???  Add warnings??  Or
document "if you want easy merges, stick to these merging styles"?


Well, one "crazy" use that I wish arch handled just a little bit better was the case of extracting a sub-project from a main project. First off, I have to say kudos to arch that it handles it at all. Here is the situation:

I have a source tree with maybe 3000 files in it. I'm new to the project, the other people are using CVS. So I wrap the whole tree up in a arch repository. This actually works pretty well. You have to take some care because CVS seems to like to update the timestamps in it's "Entries" files, even when the files haven't changed. So you can get some spurious changes, but nothing terrible.

However, trying to check this project out on windows (tla-cygwin) is not very nice at all. tla update is measured in minutes, not seconds.

So, I broke it up into smaller projects (using the directory hierarchy), and create a config. Now a changes/update/commit only looks at a small section of the overall tree.

So here is the amazing part, and the small cruft.
I used tag to create the other projects, and then in the first patch, remove all the other files.

If I sync-tree against patch-1, then the big changes never show up. And star-merge works quite well for any modifications. Yippee!!!

So the problems:
First additions. If I add a new file (or rename a file), star-merge tries to do an absolute path in the big project. So a file in
Shows up in
Even though sub1 is not a valid directory. In fact, the only way to find it is to run 'tree-lint' and see that a directory named sub1 was created. Generally I watch out for this, and just move the files to the right place after the star-merge.

Some additions (I think it is directories) require the parent directory to exist. So after running star-merge and getting a panic. I type
'mkdir sub1; tla star-merge ...; mv sub1/* subproject/sub1'

The only reason I bring it up, is because this is definitely "weird tree" behavior. But it does 90% of what I want, and it does it very well.

Now there is 1 more weird situation. If I tag one of the sub-projects into a new branch. And over the course of time I'm merging back and forth between those two branches. If I star-merge back to the main tree, it will remove all of the files. I have to sync-tree any base-0 file of any branch that adds patches into the tree.

I hope this makes sense. I just wanted to say that I am using it, it does work, but it's somewhere that arch could do just a little bit better.

I think there was a discussion about when you got an 'add' that you would also put the id of the parent directory. The only caveat being the root directory doesn't usually have an id. But if you fix those two things, then add/move would just work across crazy changes like this.

I still don't know what is causing the 'base-0' issue.


Attachment: signature.asc
Description: OpenPGP digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]