El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió: > On Feb 17, 2008 3:34 PM, Santiago Gala <[EMAIL PROTECTED]> wrote: > > Also: you keep a long term branch for doing some refactoring, and you > > fix small bugs both in HEAD and in a release branch, merging and > > backporting/forwardporting as you go. Again, something like git makes > > the work simpler and keeps the disk requirements under control. > > In an attempt to stop some of the outright FUD in this thread before > it goes on to yet another mailing list...
outright FUD? Sorry but I don't think there is Fear, Uncertainty or Doubt in this thread. There are several testimonies of good experiences with git, and the only "downplay" of subversion has been the problems with merging, which I think are real. I would only call FUD if there had been mentions, say, to subversion corrupting repositories or similar, and I think those times are far in the past. > > I've found that svnmerge.py (distributed with SVN) handles pretty much > all of the branch/merge tracking capabilities that I personally care > about. (The drawback is that it isn't as efficient as we'd like, but Not in my copies (I tested Gentoo linux amd64, subversion-1.4.6, and a different 1.4.3 Mandriva rpm). I guess they don't ship "contrib" stuff. Linus Torvalds discusses extensively work flow processes in http://git.or.cz/gitwiki/LinusTalk200705Transcript , and I think he is mostly right in the fact that distribution is the way to go, and not just because of disconnected operation. In one of the projects I track and patch, I don't commit myself, but I have contributed a number of components and patches and I keep ongoing patches. I would never be able to use svnmerge.py without the ability to create branches or commit. > it's good enough. The 1.5 stuff is *way* faster.) From your > statements, you probably haven't bothered to try svnmerge.py (usable > with 1.4.x) or any of the new reintegrate merge stuff in 1.5. It > makes it pretty brain-dead simple to handle most branch-oriented > merging cases. There are a few pathological cases that don't work > well, but that's 'reflective' merging which isn't the 95% use case - > so it got punted to post-1.5. (svnmerge.py is probably the 80% use > case, with 1.5 merge tracking being 90%, and reflective merging being > that last gap...) > FWIW, for svn.apache.org, I have a feeling we'll probably be a tad > aggressive on rolling out 1.5. > (Besides merge tracking, there are a number of excellent features in > 1.5: changelist support, interactive conflict resolution, read/write > transparent proxies, integrated 'diff -x -p' support, substantial > svnsync speed improvements, partial svnsync ability, etc.) Note that > nothing is stopping you from using svnmerge.py today. If folks are > going to complain about switching to another SCM because of a lack of > decent merging, then they owe it to themselves to check out what > Subversion can actually do rather than what they think it can do... > -- justin Well, I tried svk, git, mercurial and bzr. I am even using darcs because of some openID code I track. I prefer git, even when forced to use git-svn, to svk. Still, I will try to look into svnmerge.py, I found it here http://www.orcaware.com/svn/wiki/Svnmerge.py Regards Santiago > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
