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

[Zenaan Harkness]

On Fri, 2004-09-24 at 12: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

Don't know for sure, but I think so - the SCCS dirs are embedded in the
tree.

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

This is true, although is pretty easy to get around - either be default
checkout everything in edit mode (a config option) or alias your editor
command to call "bk edit $EDITOR" which does the right thing. Of course,
environments like EMACS can also be configured to do the right thing.

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

cheers
zen