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

[Dustin Sallings]

On Sep 23, 2004, at 19:00, Miles Bader wrote:

> Zenaan Harkness <address@hidden> writes:
> >         in bitkeeper, a tree is an archive is a tree;
>
> Does this mean if you "get" (in tla-speak) a new project tree, the size
> includes the entire project history (in SCCS-compatible form)?  That
> seems, um.... rather to discourage making new project trees, which is a
> shame -- one of the things I love about arch is that with a local
> archive or a good revision library, you can easily "get" tons of 
> scratch
> trees to play around with (for doing particularly tricky merges or
> something), even if the source tree is quite large.

	I've not used bk, but I have used darcs which has this model.  You can 
do partial tree checkouts, though (i.e. from a given tag).

	The advantage is that checking out a tree (darcs get) leaves you with 
a directory in which you can edit and record patches in directly, and 
from which merges can be pulled.

	I.e. consider the process of making changes to a foreign project in 
arch versus darcs:

        arch:
                tla make-archive
                tla tag
                tla get

        darcs:
                darcs get


        Pulling new changes:

        arch:
                tla star-merge
                tla commit

        darcs:
                darcs pull


	The important distinction is that you have to consciously and sort of 
formally branch in arch whereas there's no need to consider whether you 
might have write access to the repository from which you're pulling.  I 
can't really say which model I prefer yet, though.  There are clear 
advantages to each approach.

        As for getting tons of scratch trees:

        darcs get /path/to/tree

	Will (attempt to) produce hard links to the patches rather than 
copying them.  Still can be heavier than arch, but you can do a partial 
get there, too.  This model seems to be more conducive to lots of small 
short-term or ``micro'' branches.

> Some other points I've heard about bitkeeper (never used it though [not
> allowed too!]):
>
>   * It apparently requires you to declare which files you change before
>     you change them ("bk edit" command I think).  This would obviously
>     allow bitkeeper to work very speedily because it can avoid diffing
>     large trees, but could be pretty annoying for the user, especially
>     one used to CVS or other "relaxed" systems.

	I use perforce at work, and I can say that the speed difference is 
really worth any perceived inconvenience there.  For me, I've got a vim 
macro (\o) that will open whatever file I'm working on for edit, and 
another (\pa) that will open the current file for add.

	I spent a good hour and a half playing with arch trees on a plane 
trying to make some minor changes.  Commits would take a good five 
minutes for each change (after about as long for a changes).  It was 
basically unusable.

	I was working on a branch of a tree with a lot of patches (migrated 
directly from p4 changesets) and a lot of files using explicit tagging 
and a greedy revlib if anyone's wondering.

>   * 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.

	darcs will allow merges on trees with no common ancestry.  It actually 
makes quite a bit of sense, but probably isn't right for every project. 
 For example, you may have two projects that are somewhat similar such 
that one has ``code/'' and another has ``docs/''.  It'd be very simple 
to merge those two together into one project.

--
SPY                      My girlfriend asked me which one I like better.
pub  1024/3CAE01D5 1994/11/03 Dustin Sallings <address@hidden>
|    Key fingerprint =  87 02 57 08 02 D0 DA D6  C8 0F 3E 65 51 98 D8 BE
L_______________________ I hope the answer won't upset her. ____________