Mailing-List: contact general-help@incubator.apache.org; run by ezmlm
Precedence: bulk
Reply-To: general@incubator.apache.org
Received-SPF: pass (athena.apache.org: domain of santiago.gala@gmail.com
 designates 72.14.220.159 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=gmail.com; s=gamma;
        h=subject:from:to:in-reply-to:references:content-type:date:message-id:mime-version:x-mailer:content-transfer-encoding:sender;
        b=EpgaFOp7qmik1N/lpMMupiEnwt2ffat3VUYE1rbejEPEPlQx3B5zItDboGWRA6cSBLQMsDCPmUbrdF0RyzTFkEddD7wTlsDguNO4JbCXX8xNrbokiYXfOjCtwqWOTJwoZ9Jbyxpa5NWaVx01ZOWeOquKEnwXHvX+e2HaiS/S8bw=
Subject: Re: Subversion vs other source control systems
From: Santiago Gala <sgala@apache.org>
To: general@incubator.apache.org
In-Reply-To: <5c902b9e0802171724i36696280r882b7d9bd98f554c@mail.gmail.com>
References: <NBBBJGEAGJAKLIDBKJOPGEOICKAD.noel@devtech.com>
	 <A7B1BC35-87C7-483A-B5F2-4E5483197707@leosimons.com>
	 <1203291270.27742.56.camel@marlow>
	 <5c902b9e0802171724i36696280r882b7d9bd98f554c@mail.gmail.com>
Content-Type: text/plain; charset=utf-8
Date: Mon, 18 Feb 2008 19:48:01 +0100
Message-Id: <1203360481.23493.78.camel@marlow>
Mime-Version: 1.0
Content-Transfer-Encoding: 8bit
Sender: Santiago Gala <santiago.gala@gmail.com>


El dom, 17-02-2008 a las 17:24 -0800, Justin Erenkrantz escribió:
> On Feb 17, 2008 3:34 PM, Santiago Gala <sgala@apache.org> 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: general-unsubscribe@incubator.apache.org
> For additional commands, e-mail: general-help@incubator.apache.org


---------------------------------------------------------------------
To unsubscribe, e-mail: general-unsubscribe@incubator.apache.org
For additional commands, e-mail: general-help@incubator.apache.org