monotone-devel
[Top][All Lists]
Advanced

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

[Monotone-devel] Re: no more bitkeeper for linux?


From: Bruce Stephens
Subject: [Monotone-devel] Re: no more bitkeeper for linux?
Date: Thu, 07 Apr 2005 21:14:43 +0100
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

address@hidden writes:

[...]

> Anyway, this might be still a good opportunity to increase the
> number of people aware of the great functionality offered by
> Monotone.

My guess is that right now isn't the right time.  monotone is
unusually slow just at the moment.

I think a few messages in the thread are worth reading.

<http://kerneltrap.org/mailarchive/1/message/48810/thread>
<http://kerneltrap.org/mailarchive/1/message/48857/thread>

Specifically Linus's message explaining what he likes about
BitKeeper's lack of support for cherry-picking, Al Viro's reply, and
some of the replies to Al Viro (including Linus, of course).

That usage---where you're using an SCM to prepare changes that you're
going to send somewhere else, and having done that the detailed
history is relatively uninteresting---strikes me as common.  

That's much how I'm using svk at work, for example (and was using
monotone, and probably will again): I'm using the SCM to keep track of
day to day work (where once upon a time I guess I'd have just made
copies), and when I've got something suitably clean it goes into our
CVS repository.  And once the nice clean change has gone into CVS, I
don't care much about the detailed history.

Ironically, I think GNU Arch doesn't do this all that well.  It
supports cherry-picking, but it remembers all the details, and often
they're just clutter.  Worse than that, it'll remember all the
archives from which changes come, and (unless this has been fixed,
which it may well have been), one or two operations ("tla ancestry",
for example) will insist on trying to connect to them all.

(I don't know how a system might cleanly support this kind of usage.
My guess is that an acceptable way to do it is to have some branches
which are deleteable, just for messing about (and maybe just creating
throwaway repositories would be OK with monotone), and doing the
combination outside of the SCM, perhaps using quilt or something for
complex cases.  If that's so, then no changes would be needed, I
guess.)




reply via email to

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