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 daniel.haischt@googlemail.com
 designates 72.14.246.246 as permitted sender)
DomainKey-Signature: a=rsa-sha1; c=nofws;
        d=googlemail.com; s=gamma;
        h=message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references;
        b=Z+jVQ7Wvw428xX47dunl2xqUYNOOrEksDwKGT2IpQkp7CkDrfgNNd1cLxgFN1Nunz0fKZgoBR3aO1oqiVjN/NkHRUrHuEmNLibQ+7LvccdNWYbkey9MvWdhh1B0zrR53Meu83Y7Ti8LerSH5b9yM0Irjf9fP73WUklD5E5EMDx8=
Message-ID: <eff8c4060802140503q4fe0a65fr2e40246c8438f37d@mail.gmail.com>
Date: Thu, 14 Feb 2008 14:03:32 +0100
From: "Daniel S. Haischt" <daniel.haischt@googlemail.com>
To: general@incubator.apache.org
Subject: Re: Subversion vs other source control systems
In-Reply-To: <1202993747.22816.83.camel@marlow>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <NBBBJGEAGJAKLIDBKJOPEEBKCKAD.noel@devtech.com>
	 <47B42516.2030103@apache.org>
	 <9BCD483D-118B-4D14-8472-3CF7A47C995E@webweaving.org>
	 <1202993747.22816.83.camel@marlow>

would SVK be an option? This would allow to re-use the already existing SVN
infrastracture.

No need for changes to the ASF infrastructure...

On Thu, Feb 14, 2008 at 1:55 PM, Santiago Gala <sgala@apache.org> wrote:
>
>  El jue, 14-02-2008 a las 12:37 +0100, Dirk-Willem van Gulik escribi=F3:
>
> > On Feb 14, 2008, at 12:25 PM, Ross Gardler wrote:
>  >
>  > > Noel J. Bergman wrote:
>  > >> J Aaron Farr wrote:
>  > >>> J Aaron Farr wrote:
>  > >>>>> git could be an issue.
>  > >>>> Can you explain what the issue is with Git?
>  > >>> Leo already gave a decent explanation.
>  > >>> Basically, it comes down to two aspects:
>  > >>>  1) infrastructure support
>  > >>>  2) cultural bias
>  > >> Only the first one is marginally correct, IMO.
>  > >> Santiago wrote:
>  > >>>> 1. You have to use subversion.
>  > >
>  > >
>  > > Sorry, I've missed the thread that led to this, so sorry if I'm
>  > > repeating others.
>  > >
>  > > I understand that GiT can be used locally as a layer on top of SVN.
>  > > I believe this gives you most of the perceived benefits of GiT
>  > > locally without the need for a project itself to switch to GiT.
>  >
>  > I am a bit lost here as well -- what does GiT add to the processes/
>  > workflows common in the ASF ?
>  >
>
>  It adds:
>  - ability to have offline commits
>  - much faster repository diff, status, etc. that works offline
>  - (git-specific) ability to reorder and aggregate several private
>  commits to deliver a consistent patch. This can only be simulated with
>  other tools
>  - ability to publish (push/pull) branches easily for tests without
>  compromising the main line. Subversion branches, while easy to create,
>  are awful to maintain and rarely used.
>  - clean and remembered merges: patches with clear attribution that can
>  be merged multiple times which, again, makes easy maintenance of several
>  branches running in parallel.Backports, etc.
>
>
>
>  > One of the great things about GiT is that you can can have lots of
>  > parallel and non-linear merges (every developer their own branch; lots
>  > of people merging the same patch into different sequences) -- and as
>  > such I can see it being perfectly tuned for, say, Linux.
>  >
>
>  Precisely the fact that patches are accepted in just 'one' or 'a few'
>  points make invaluable having good maintenance of in-progress work.
>
>
>  > However in the ASF most groups work roughly along fairly linear lines;
>  > with 'one' or just a 'few' points at which a patch is accepted - and
>  > essentially few, or just one, merge point (or a single line of merge
>  > points when backported). Rarely do we merge multiple 'HEAD's.
>  >
>
>  Not in my experience, it is common to have in-progress work in parallel
>  with bugfixes, etc. subversion is awful for tracking multiple branches
>  in parallel, to the point that I have been using quilt for patch
>  management of top of subversion. This is clearly a kludge that reveals
>  the deficiencies of the workflow.
>
>  You see? "rarely do we merge multiple HEADs" is seen from the point of
>  view of the repository. If you have 10 developers working on patches,
>  you have 10 people merging continuously their branch with the "official"
>  one. Rarely applies only to the subversion repo.
>
>
>  > And I'd almost argue that SVN is a useful framework which helps us
>  > stay on the paved roads - where a single head progresses with group
>  > consensus and generally agreed merit.
>  >
>
>  I've seen plenty of times where having in-progress patches were
>  consistently conflicted by commits, which multiplied the work implied in
>  keeping them to the point of dropping them (personal). This is trivially
>  easy to do with bazaar or git, and I'm quite sure that darcs or
>  mercurial will offer the same comfort level.
>
>  At least for my development style, distributed SCM offers one order of
>  magnitude more comfortable environment than centralized SCM.
>
>  As for your concrete sentence, I'd say that if you need a technical tool
>  as a framework to impose a work flow, then the work flow is possibly
>  broken. If the work flow is sound, having a tool that eases the work
>  won't break it.
>
>  Regards
>  Santiago (who was working to deliver this and more info on technical
>  merits in the community@apache.org thread)
>
>
>
>  > Thanks,
>  >
>  > Dw
>  >
>  > ---------------------------------------------------------------------
>  > 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
>
>

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