
On 2/2/11 4:12 AM, in article iib75a$v6a$1@dough.gmane.org, "Vladimir Prus" wrote:
So the incentives associated with SVN encourage you to keep changes on your local disk, with no logical separation or comment about their meaning until you're ready to show them. Working on a fix for something and need to handle an emergency somewhere else? Do you check in what you're working on and go back to a clean state to handle that emergency? With SVN I almost never did. With Git it's easy and fast, and doesn't expose incomplete work to the world, so I always do.
It's also true. It's also true that git has some features that help with that. But, it does not mean Boost repository should be git.
I am primarily using git to keep local patches against various projects, which use Subversion and CVS. In some cases, it's a substantial convenience. E.g. when a patch review turnaround can be a week, it's nice to put a sequence of patches on a git branch. Note however, that git is not necessary the only, or the best answer. Some folks who are way more effective that myself in dealing with patch series use quilt, and it works just fine desprite not having any hype around. And, if you prefer git, you can use git-svn just fine. This will solve all your issues above.
It is true that having Boost use git will make it slightly more convenient to use git on your computer. However, only slightly more. And the downsides are:
- Transition costs - Ongoing problems for new folks who are not familiar with git - Quirky ideas about how you should to version control that git appears to enforce on its users - That cherry-pick deficiency - And, finally, a serious risk that as soon as Boost switches to git, everybody will get excited, create 100 clones everywhere, and everybody will spends days sending and merging pull requests, while there will be no official version. This is of course, a process problem, but given our track record of ignoring process problems and focusing at not too important discussions, I bet we would not be able to fix this.
Been following along silently since the beginning. Just a couple of comments here: There are ongoing problems with new users and SVN. Boost is the ONLY project that I use that uses SVN. Every time I want to hack on boost I have dig out my notes and get back up to speed on SVN. What is stopping anyone from creating their own SVN server with Boost on it? A Simple google search will point the way to the "Official" boost SVN repository. So neither one of those arguments are really valid in my mind. I dont' have enough experience to comment on the other issues that you raise. Mike Jackson