Comparison with Git, Mercurial or Darcs?

[Daniel Carrera]

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


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

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.
> <URL:http://doc.bazaar-vcs.org/bzr.dev-html/en/tutorials/centralized_workflow.html>.

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


Daniel.
-- 
No trees were killed in the generation of this message. A large number
of electrons were, however, severely inconvenienced.