[Top][All Lists]

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

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

From: Dustin Sallings
Subject: Re: [Gnu-arch-users] Re: bitkeeper vs tla
Date: Thu, 23 Sep 2004 20:17:38 -0700

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:

                tla make-archive
                tla tag
                tla get

                darcs get

        Pulling new changes:

                tla star-merge
                tla commit

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

reply via email to

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