DCVS vs CVS: call for constructivism
Hello, I think we all know understood that there are people from both camps, some with emotional arguments, some with constructive arguments, but it's not really moving anywhere. We need to start listing what would have to be done and once we have such a map see if it's worth it before discussing pointless things. Just so we can redirect people saying things like "Nobody told me a real advantage yet" to this post, here's a recapitulation of what I think the advantages/disadvantages of a DCVS is ( http://www.ericsink.com/vcbe/html/dvcs_advantages.html, http://www.ericsink.com/vcbe/html/dvcs_weaknesses.html): Pro: - Offline work (you can use diffs, you can commit) - Speed of operations compared to svn - No need to setup a server to work locally (encourages participation (focus on working first, then sharing later)) Cons: - Cannot check out subpaths - Cannot lock files - Would require people to change their habits and learn new tools I think most people in the svn-camp will tell that with the 1.8 checkpoints feature you can now also commit while offline and thus the only advantages for DCVS seems to be speed and the ability to check all the data while offline. I think the people that are opposed to the change unfortunately won't be convinced by those arguments, even tho pretty much every who switched to DCVS will tell you that the advantages are worth it and it's more than simply speed or freedom, it's a philosophy etc. So I think the best thing to do now is first to make a map of what would have to be done if we decided to switch, to see if it's an option at all. Here's a simple draft, please participate into making it better: - Import current history - Migrate the existing hooks - Migrate the existing scripts around. - Migrate the test runners - Trac / Website integration (redmine with git extensions?) - Rights management (gitolite?) - Update release procedures Maybe we'd start a page on the wiki, but the idea is to find out if there are more steps to be done and if there's any showstopper in those steps. I think the best solution would be to offer the repository with several protocols, namely git/hg/svn so everyone could use the tool they want (e.g github offers svn/git, I know other hosts do it too). Philippe
Constructive while insightful would be great, i.e., to hear from people have extensive experience with BOTH (kinds of) systems, rather than people being used to X and having heard (good and bad rumors) about Y. I happen to be one; and for me, it is a no-brainer. That is not to say that I did not use my brain to some extent while concluding, constructively ;-), that Git is far superior to SVN. Regarding learning curve: yes, the learning curve for Git is steep; it might necessitate one full day (...) of focused training to get the concepts and file system (abstraction and concretely) pieces. In my extremely humble opinion, it is well worth to allocate 10 solid hours into something one uses daily for at least seven years; especially for a tool like Git that actually does affect the way one approaches development processes a bit, and in my still humble opinion, does so in a positive way. Come on guys, I promise that it is worth one full day to get into Git; if nothing else, it might invoke some (branching) thought patterns that could be useful for your SVN (or CVS...) efforts :-) Once, everybody involved in this discussion have indeed used both systems, we can have a truly constructive dialog. Regarding not being able to check out sub paths and deal with them , that is not entirely true, as Git, at least, enables one to dissect a file tree, with commands like "git read-tree", "git write-tree" and "git merge -s subtree". Simple? Nope, but powerful. That is actually a theme of Git: few and simple (graph-theoretical) concepts and quite hairy commands to get to them, with seemingly arbitrary names, hiding the simplistic beauty behind the scenes. A huge PRO for Git is the simple command git stash which hides away all the current local changes (and state) into a temporary stack, so you can resolve underlying/other issues and then get back to where you were via git stash apply Very handy, and very frustrating not to have that in SVN. /David On Mar 22, 2012, at 4:47 AM, Philippe Vaucher wrote:
Constructive while insightful would be great, i.e., to hear from people have extensive experience with BOTH (kinds of) systems, rather than people being used to X and having heard (good and bad rumors) about Y. I happen to be one; and for me, it is a no-brainer. That is not to say that I did not use my brain to some extent while concluding, constructively ;-), that Git is far superior to SVN. Regarding learning curve: yes, the learning curve for Git is steep; it might necessitate one full day (...) of focused training to get the concepts and file system (abstraction and concretely) pieces. In my extremely humble opinion, it is well worth to allocate 10 solid hours into something one uses daily for at least seven years; especially for a tool like Git that actually does affect the way one approaches development processes a bit, and in my still humble opinion, does so in a positive way. Come on guys, I promise that it is worth one full day to get into Git; if nothing else, it might invoke some (branching) thought patterns that could be useful for your SVN (or CVS...) efforts :-) Once, everybody involved in this discussion have indeed used both systems, we can have a truly constructive dialog. Regarding not being able to check out sub paths and deal with them , that is not entirely true, as Git, at least, enables one to dissect a file tree, with commands like "git read-tree", "git write-tree" and "git merge -s subtree". Simple? Nope, but powerful. That is actually a theme of Git: few and simple (graph-theoretical) concepts and quite hairy commands to get to them, with seemingly arbitrary names, hiding the simplistic beauty behind the scenes. A huge PRO for Git is the simple command git stash which hides away all the current local changes (and state) into a temporary stack, so you can resolve underlying/other issues and then get back to where you were via git stash apply Very handy, and very frustrating not to have that in SVN. /David On Mar 22, 2012, at 4:47 AM, Philippe Vaucher wrote:
As someone with the same experience I can only agree with you. Unfortunately many boosters seems to express the desire to avoid having to put many efforts into learning a new tool. While I disagree with them (constantly learning new stuffs is part of a developper's job imho), it's hard to tell them they're wrong, especially since the people objecting are active maintainers. Honestly, I'm really not sure what will happen... the main problem is that for people not used to DCVS the current situation is fine, while it is far from ideal (if not horrible) for the rest. Seems that whatever we choose some people are going to be hurt. As I said, probably that the best option would be to serve the repo using multiple protocols, not sure how feasible it is while satisfying both workflows. Philippe
On 03/23/2012 10:38 AM, Philippe Vaucher wrote:
I strongly suggest to reconsider that wording. Accusing anybody not trying to learn new stuff is just rude. I admit that many objections are based on fear, uncertainty and doubt. In order to put those aside, a fully worked out proposal on how the migration and will be helpful. As far as I understand this will be done by Beman when he gives his talk at C++Now!. Anything discussed here before is just a big pile of assumptions etc. I am sure that a decision can, and will be made after the conference.
I'm sorry my goal is really not to offend people. I tried to express the current state: some people seem really against changing their workflow. Probably that it has nothing to do with learning, even tho I'm surprised we have to explain the DCVS advantages to people when this is a relatively old concept that developpers should already be familiar with in my (ideal) world. That said, you're right, let's see what comes out of Beman's talk. It'll probably remove a lot of FUD away and outline a more concrete migration plan that people can focus their attention to instead. Philippe
On 3/23/2012 5:38 AM, Philippe Vaucher wrote:
It is not learning a new tool. Programmers doing that constantly. It's in trying to understand why the current tool is apparently inadequate for many so that a new tool is necessary to fix those inadequacies.
What is "far from ideal (if not horrible)" about the current situation with Boost and SVN ? Please be specific.
What is "far from ideal (if not horrible)" about the current situation with Boost and SVN ? Please be specific.
I think the discussions have shown that it's hard to be specific and convincing about this topic, but see the list of pros/cons I made in my original post and also the posts from Beman and Julian. You won't find individual points where DCVS seem to really outperform/outfeature the classic CVS, but together as a whole it really makes a difference for a lot of people. I agree that "horrible" is probably too far streched, sorry for that... but I think the current situation frustrates people, and it eventually gets on their nerves. Philippe
On 3/26/2012 4:37 AM, Philippe Vaucher wrote:
This is my point about the move from a CVS like SVN to a DVCS like Git ( or Mercurial ). I really do not understand the necessity for it based on use cases which are causing people to feel that a change should be made. I do hear general reasons why some people are more comfortable with a DVCS but since switching is going to cause me to have to learn a new set of techniques for working with version control and Boost libraries, while I am already quite comfortable with the current SVN system and its capabilities, you can understand why I do not see the reason for having to make this change. Simply saying that X is better because of some general reasons, which do not apply IMO to actual usage. does not make me want to do something different in programming and programming tools.
Edward Diener <eldiener@tropicsoft.com> writes:
It's useful to separate features that are an improvement over SVN while not being DVCS-oriented from features that are only available in a DVCS. As a git user, I would list the following in the first class: - git stash, which helps a lot when an interrupting issue takes you off into a separate project (usually a bugfix) - The index, which helps separate what you've changed from what you will commit (it is the index that allows cools things like "git add -i") - A better merge algorithm git features which depend on a DVCS model include: - Truly private branches (i.e. no one ever sees them or even knows they exist) -- these are often called "feature" or "topic" branches - git rebase, which lets you explore a line of development and clean up the history after the fact - First-class support for vendor branches/upstream code drops The above is just a sample, the things that popped into my head right away. There are other, more subtle advantages to git over svn. It's important to stress that each of these features, whether necessitating a DVCS model or not, exist in git and DO NOT exist in svn. So from a practical standpoint, it doesn't matter whether one buys into the DVCS model. The features are not in svn and so should be counted as a git advantage. A big one, IME. git can be used in a perfectly centralized way. I don't know why one would want to do that, but it is possible. -Dave
Edward Diener wrote:
I think Philippe was being too modest here. Git DOES outperform svn (faster operations, slightly better merging) and outfeatures it in several ways, as illustrated by Dave (from Cray) in the previous post.
Evidently there is no necessity, otherwise Boost would have switched already. The discussion seems to be rather on whether the benefits outweigh the costs. I'm starting to think that perhaps we're disagreeing more about the costs than about the benefits.
I do hear general reasons why some people are more comfortable with a DVCS but since switching is going to cause me to have to learn a new set of techniques for working with version control and Boost libraries, while I am already quite comfortable with the current SVN system and its capabilities, you can understand why I do not see the reason for having to make this change.
What you say here seems to be more about your comfort than about performance, features, necessity of switching or the comfort of others. You're comfortable enough with svn to not want to change, unless somebody can convince you in advance that you'll be much more comfortable with git (or hg). The latter is probably impossible because people tend to only judge comfort by their own experience. (Note: several DVCS proponents in these discussions have used comfort arguments as well. Some of them have enough experience with both svn and git/hg to make a proper comparison of comfort, while some others might just be more familiar with git/hg. However, it's not all comfort arguments; less subjective, technical arguments have been given from the beginning.)
Simply saying that X is better because of some general reasons, which do not apply IMO to actual usage. does not make me want to do something different in programming and programming tools.
How do faster operations, versioned patches, versioned local work, smaller average commit size and better merging not apply to actual usage? -Julian
There's another advantage I forgot about: the ability to commit only certain parts of a file. This is really nice because often when you change something you actually do several changes at once. Being able to commit only parts of your changes on a file allows for smaller commits which only have a single responsability, making history easier to follow (and revert). For more details & rationale see the "Commit all the fucking time" at http://jeffkreeftmeijer.com/2010/git-your-act-together/ Philippe
Philippe Vaucher <philippe.vaucher@gmail.com> writes:
That's technically not a property of having a DVCS: you could also imagine committing part of a file with Subversion: save the current changes with 'svn diff', revert the file, apply part of the patch you saved, and commit before apply ing the rest of your patch. It just so happens that this feature was introduced in DVCS, I believe Darcs was the first tool to provide this feature, and since then Mercurial got 'hg record' and Git got 'git add -i'. It's a killer feature, though! :) -- Martin Geisler aragost Trifork Professional Mercurial support http://www.aragost.com/mercurial/
On 22 March 2012 11:47, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
Irrelevant for us (locking that is).
- Would require people to change their habits and learn new tools
Add: - No merge tracking for subtrees. Not necessarily a fatal disadvantage, but we do make quite heavy use of subtree merge tracking. Which is perhaps why our meta-data is such a mess. Git merging is in general saner, but might not match our current use.
On Thu, Mar 22, 2012 at 7:47 AM, Philippe Vaucher <philippe.vaucher@gmail.com> wrote:
That's just one example of more general advantage: distributed version control systems support many workflows that range from messy to difficult to downright impossible with non-distributed VCS systems, and make it easier for different Boost developers to use a workflow that suits their particular needs.
What about ease of modularization and breadth of community support? What about developer preference? My impression is that a sizable majority of developers who have used both distributed and non-distributed VCS come to prefer distributed.
Focusing on checkpoints trivializes the advantages of distributed VCS, IMO.
What you are suggesting seems to be what the Ryppl folks been working on for several years now. --Beman
Good points. About developer preferences, this is why I'm trying to suggest the best solution might be a multi-protocol repository. For example, github can serve over svn & git, I know other hosting solutions provide similar features.
You're right that the migration probably overlaps a lot with what Ryppl tries to achieve. I hope for everyone's best that both will move forward as a result. Philippe
Philippe Vaucher wrote:
If I understood correctly the ryppl project has several aims: - migration to git - migration to cmake - modularization, together with some form of package management (the latter is perhaps the real aim, while the former two are just means to an end) So my impression is that Philippe was trying to cover only about a third of what the ryppl folks have been working on. Which of course may still mean that some form of redundancy is going on. Either way, I think it has been argued elsewhere that isolating the migration to git from the other steps would be a good idea. -Julian
Philippe Vaucher wrote:
I just wanted to say that I find this a good initiative. Although I agree with Thomas that it would make sense to wait for Beman's talk.
I would add: - More encouraging to use small commits, especially on large projects - Versioned patches Kind regards, Julian
Philippe Vaucher <philippe.vaucher@gmail.com> writes: Hi everybody, Thanks for a good discussion about DVCS. Since the discussion seems to have quiet down, I'll unsubscribe again in a couple of days. I hope I could help answer some questions about what DVCS brings to the table and explain some of the common misunderstandings. Feel free to Cc me in the future if there is anything I can help with. Good luck with the project!
-- Martin Geisler aragost Trifork Professional Mercurial support http://www.aragost.com/mercurial/
participants (10)
-
Beman Dawes -
dag＠cray.com -
Daniel James -
David Bergman -
Edward Diener -
Julian Gonggrijp -
Martin Geisler -
Pedro Larroy -
Philippe Vaucher -
Thomas Heller