Skip to main content
Question Protected by maple_shaft

I'm a Subversion geek, why I should I consider or not consider Mercurial or Git or any other DVCS?

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin FowlerMartin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

Updated
Source Link
user2567
user2567

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

I try to understand the benefits of distributed version control system (DVCS).

I found Subversion Re-education and this article by Martin Fowler very useful.

Mercurial and others DVCS promote a new way of working on code with changesets and local commits. It prevents from merging hell and other collaboration issues

We are not affected by this as I practice continuous integration and working alone in a private branch is not an option, unless we are experimenting. We use a branch for every major version, in which we fix bugs merged from the trunk.

Mercurial allows you to have lieutenants

I understand this can be useful for very large projects like Linux, but I don't see the value in small and highly collaborative teams (5 to 7 people).

Mercurial is faster, takes less disk space and full local copy allows faster logs & diffs operations.

I'm not concerned by this either, as I didn't notice speed or space problems with SVN even with very large projects I'm working on.

I'm seeking for your personal experiences and/or opinions from former SVN geeks. Especially regarding the changesets concept and overall performance boost you measured.

UPDATE (12th Jan): I'm now convinced that it worth a try.

UPDATE (12th Jun): I kissed Mercurial and I liked it. The taste of his cherry local commits. I kissed Mercurial just to try it. I hope my SVN Server don't mind it. It felt so wrong. It felt so right. Don't mean I'm in love tonight.

FINAL UPDATE (29th Jul): I had the privilege to review Eric Sink's next book called Version Control by Example. He finished to convince me. I'll go for Mercurial.

added 242 characters in body; edited tags
Source Link
user2567
user2567
Loading
added 65 characters in body
Source Link
user2567
user2567
Loading
Reworked question and removed beliefs
Source Link
user2567
user2567
Loading
Rollback to Revision 8
Source Link
user8
user8
Loading
Rollback to Revision 6
Source Link
user2567
user2567
Loading
added 63 characters in body
Source Link
user2567
user2567
Loading
copyediting
Source Link
user8
user8
Loading
edited tags
Link
Ken Bloom
  • 2.4k
  • 17
  • 20
Loading
Added Martin Fowler article
Source Link
user2567
user2567
Loading
Reworked question; added 53 characters in body
Source Link
user2567
user2567
Loading
added 1132 characters in body; added 159 characters in body
Source Link
user2567
user2567
Loading
added 84 characters in body
Source Link
user2567
user2567
Loading
Source Link
user2567
user2567
Loading