Edward Diener <eldiener@tropicsoft.com> writes:
Also back to the point - DVCS are written to provide best possible support for merging. This makes 1) or 2) you propose above very efficient. In SVN or other centralized systems it is not so, just look up the bit I left from Joel's message above.
I do not believe for even a second that any product can do merging of the same source file automatically and flawlessly.
This strawman keeps resurfacing. No one has claimed than any VCS can avoid manual merging at times. A centralized VCS needs to operate as you outlined:
Bu how is this different from:
1) Creating a local SVN repository and importing some branches from another SVN repository.
and/or
2) Having one's own branch of an SVN repository as one's own.
#1 is a horribly manual operation. I don't know if you quite grasp how complicated it is. I've been doing it for years. Getting the history preserved correctly is not trivial. #2 has almost no support in SVN. Now that SVN has merge tracking it is marginally better but there are problems with this model. Foremost, the branch has to be in a centralized repository and everyone owkring on the project has to deal with it in some fashion. It's not private in any sense of the word. You can't work on it if you don't have 'net access. You can't back out changes that you realized later were bad and ensure no one else ever sees those changes. The difference with a DVCS is both #1 and #2 are natively supported in the tool. There is no difference between a private local branch, a remote branch in a _de_facto_ central repository and a remote branch in some other random repository. They all look and act the same. I admit it is a tough concept to grasp for someone not used to it. It took me some time to grok it. But now it is second-nature to me and there's no way I'm going back. -Dave
On 3/22/2012 5:11 PM, David Greene wrote:
Edward Diener<eldiener@tropicsoft.com> writes:
Also back to the point - DVCS are written to provide best possible support for merging. This makes 1) or 2) you propose above very efficient. In SVN or other centralized systems it is not so, just look up the bit I left from Joel's message above.
I do not believe for even a second that any product can do merging of the same source file automatically and flawlessly.
This strawman keeps resurfacing.
No one has claimed than any VCS can avoid manual merging at times.
While automatic merging of any single language source code file may actually work and produce output that is correct, I personally would never trust it without having to manually check it. This is why I object to the advantage which is claimed for DVCS systems that merging being done better with them ( presumably because local commits are part of the history when pushing to another repository ) is some great advantage.
A centralized VCS needs to operate as you outlined:
Bu how is this different from:
1) Creating a local SVN repository and importing some branches from another SVN repository.
and/or
2) Having one's own branch of an SVN repository as one's own.
#1 is a horribly manual operation. I don't know if you quite grasp how complicated it is. I've been doing it for years. Getting the history preserved correctly is not trivial.
I agree with you it is not easy, but it is doable in SVN. I also agree that a DVCS system makes it normal and natural.
#2 has almost no support in SVN.
I do not understand your remark, What is so hard in SVN of granting certain users access to certain parts of a repository, and how can you say it has no support in SVN ?
Now that SVN has merge tracking it is marginally better but there are problems with this model. Foremost, the branch has to be in a centralized repository and everyone owkring on the project has to deal with it in some fashion. It's not private in any sense of the word. You can't work on it if you don't have 'net access.
You can't update or commit without access to an SVN repository, but this has nothing to do with restricting access to any part of an SVN repository, which is a no-brainer in SVN.
Edward Diener <eldiener@tropicsoft.com> writes:
On 3/22/2012 5:11 PM, David Greene wrote:
Edward Diener<eldiener@tropicsoft.com> writes:
Also back to the point - DVCS are written to provide best possible support for merging. This makes 1) or 2) you propose above very efficient. In SVN or other centralized systems it is not so, just look up the bit I left from Joel's message above.
I do not believe for even a second that any product can do merging of the same source file automatically and flawlessly.
This strawman keeps resurfacing.
No one has claimed than any VCS can avoid manual merging at times.
While automatic merging of any single language source code file may actually work and produce output that is correct, I personally would never trust it without having to manually check it.
You should always check the result of a merge -- that applies to both centralized and decentralized version control.
This is why I object to the advantage which is claimed for DVCS systems that merging being done better with them ( presumably because local commits are part of the history when pushing to another repository ) is some great advantage.
The claim is that DVCS merge better than centralized tools. I've already described that the ability to to merge well isn't tied to being decentralized or not. It just so happens that you merge more often in decentralized tools and so these tools have had to invest more energy into making merging work really well. Subversion now has merge tracking -- it should therefore be able to do merges as well as Mercurial and Git. However, it still doesn't handle simple cases like merging changes into renamed files: http://stackoverflow.com/a/2486662/110204 To repeat: the problem is not that SVN is centralized, the problem is bugs and unhandled corner cases in its merge support. Git and Mercurial don't have these bugs and so we say that they merge better. Btw, the local commits have nothing to do with merges: (in Mercurial) a three-way merge is based on the final result of the branches you merge and the intermediate steps are irrelevant.
Now that SVN has merge tracking it is marginally better but there are problems with this model. Foremost, the branch has to be in a centralized repository and everyone owkring on the project has to deal with it in some fashion. It's not private in any sense of the word. You can't work on it if you don't have 'net access.
You can't update or commit without access to an SVN repository, but this has nothing to do with restricting access to any part of an SVN repository, which is a no-brainer in SVN.
I think the point was that SVN requires you to work with a branch in the central repository. A DVCS allows (but doesn't require) you to work with a branch that you keep local and truly private. You're suggesting that this can be done with SVN too by creating the branch in the central repository and then restricting read and write access to it? Yes -- that is possible, but it's not a natural way to work with SVN. I also think you need to involve the SVN admin unless you can edit the access control rules yourself. -- Martin Geisler Mercurial links: http://mercurial.ch/
On 3/24/2012 2:20 PM, Martin Geisler wrote:
Edward Diener<eldiener@tropicsoft.com> writes:
snip...
You can't update or commit without access to an SVN repository, but this has nothing to do with restricting access to any part of an SVN repository, which is a no-brainer in SVN.
I think the point was that SVN requires you to work with a branch in the central repository. A DVCS allows (but doesn't require) you to work with a branch that you keep local and truly private.
You're suggesting that this can be done with SVN too by creating the branch in the central repository and then restricting read and write access to it? Yes -- that is possible, but it's not a natural way to work with SVN.
This depends purely on how you work. I have worked in places where the SVN repository was setup to section off who could work with what on the same repository or different repositories. There is nothing NOT natural in this and saying that "it's not a natural way to work with SVN" shows a clear bias.
Edward Diener <eldiener@tropicsoft.com> writes:
On 3/24/2012 2:20 PM, Martin Geisler wrote:
Edward Diener<eldiener@tropicsoft.com> writes:
snip...
You can't update or commit without access to an SVN repository, but this has nothing to do with restricting access to any part of an SVN repository, which is a no-brainer in SVN.
I think the point was that SVN requires you to work with a branch in the central repository. A DVCS allows (but doesn't require) you to work with a branch that you keep local and truly private.
You're suggesting that this can be done with SVN too by creating the branch in the central repository and then restricting read and write access to it? Yes -- that is possible, but it's not a natural way to work with SVN.
This depends purely on how you work. I have worked in places where the SVN repository was setup to section off who could work with what on the same repository or different repositories.
I'm not saying this cannot be done. I'm saying that you need extra infrastructure to pull it off (smarts scripts, a good sysadmin, etc).
There is nothing NOT natural in this and saying that "it's not a natural way to work with SVN" shows a clear bias.
I'm a Mercurial developer and consultant -- so I have obviously bought into the idea of DVCS. I have not tried to hide that. What I have tried to do is to explain the advantages of DVCS in general. There seemed to be some confusion about what you can and cannot do with DVCS and I wanted to help clear it up. -- Martin Geisler Mercurial links: http://mercurial.ch/
participants (3)
-
David Greene -
Edward Diener -
Martin Geisler