Comparison with Git, Mercurial or Darcs?
dcarrera at gmail.com
Wed Nov 4 11:36:11 GMT 2009
On Wed, Nov 4, 2009 at 7:51 AM, Ben Finney <ben+bazaar at benfinney.id.au> wrote:
>> Ok. I guess I see your point about "darcs amend". But "obliterate" is
>> just "unrecord and revert", which bzr can do too.
> It can, but it's not something I'd ever do except when something has
> gone wrong in the VCS process. Instead, I'd simply fix the working tree
> and commit a new revision.
I don't use "darcs obliterate" just when something has gone wrong. I
use it as part of my usual workflow. When I'm working on a new feature
I send a lot of small test patches to the test server until it works.
When it works, I obliterate them on the server, unrecord them on my
laptop, and re-record them as a nice set of well organized patches.
>> Perhaps you refer to the fact that if I add features A, then B, then
>> C, I can remove feature A, so your history would change. I actually
>> like this feature.
> I've never seen a good explanation for why it would be desirable for
> anything involving a repository that might ever be shared with anyone —
> and I think it's folly to decide forever that any particular repository
> will never be shared.
If I currently share the repository with another developer who does a
little work once in a while. I only use this features in my personal
working branch or my test branch on the server. I find it very useful
for my work. When a feature is complete I push it to the public branch
where the other developer can see it, and once it's there I don't mess
>> I like that about bzr. The way I currently use darcs I actually use
>> that a lot. While I'm working on a new feature I enter a lot of
>> patches called "test", so I can push the changes to the test server.
>> When I'm satisfied with the work, I unrecord all the changes and then
>> re-record them into a nice set of patches.
> You're not describing an “oops”; you're describing an unexceptional
> “develop a feature in parallel with other development” workflow, which
> in Bazaar is done my making a feature branch to explore the parallel
> development of a feature. At any time (i.e. whenever you decide it's
> time to do so), you can merge back and forth between one branch and
You are right that I'm not describing an "oops". You are wrong that
I'm describing "develop features in parallel". Let me give an example:
Suppose that to add a feature I need to add two functions to get data
from the database and I need to change the GUI. I have to develop
these three things together at the same time, I can't develop them in
different branches. But when I record them in the end, I want to
record them as three different patches. One patch adds database
function A, the next patch adds function B, and the last patch makes a
GUI that uses A and B.
>> I must be confused, but I would have thought that any distributed VCS
>> can act like a centralized VCS if you choose to use it that way.
> No, a centralised workflow implies that the repository is in a central
> location, and is the common commit location for numerous working trees
> (used by multiple people, or multiple distinct machines by the same
> person, or both). AIUI most DVCSen can't do this.
Why not? Just make a branch that everyone in the team is allowed to
push changes to. Every time a team member wants to make a change, pull
the latest changes from the central branch, add your own changes, and
push them back to the central branch.
>> > * Directories — even empty ones — are first-class citizens
>> Ditto for Darcs. And again, I was surprised when I learned that other
>> VCS tools don't do that.
> I've had trouble using Darcs with empty directories; perhaps reverting
> them, perhaps renaming them, I can't recall. It seems to be common
> wisdom that one shouldn't have an empty directory in a Darcs project.
Nope. No problem at all. I just tested both reverting and renaming
empty directories. Directory operations are primitive patches in
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.
More information about the bazaar