Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: softfail (athena.apache.org: transitioning domain of
 andy@assembla.com does not designate 209.85.160.171 as permitted sender)
Message-ID: <4F8DBB84.3040808@assembla.com>
Date: Tue, 17 Apr 2012 14:50:44 -0400
From: Andy Singleton <andy@assembla.com>
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
 rv:1.9.2.9) Gecko/20100915 Lightning/1.0b2 Thunderbird/3.1.4
MIME-Version: 1.0
To: dev@subversion.apache.org
Subject: Re: Symmetric Merge -- Algorithm
References: 
 <CA+zztqVVjaottQ28B1Qq0=SEG8O1ZL1w2A6vbCBH+ZssLkU5HQ@mail.gmail.com>
	<CAO16vNQG0b=ZfEiiSBXPPa0gbLYrH_4Ai339WoK_kyPy7kQ1MA@mail.gmail.com>
	<4F8D91CD.4080105@assembla.com>
 <CAO16vNTYsKTXOOJ-uOyeuBMKO1UVTaKKL2uL=U1NJ0UN1s01tg@mail.gmail.com>
 <4F8D9D01.8030400@assembla.com> <4F8DB688.10905@apache.org>
In-Reply-To: <4F8DB688.10905@apache.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: quoted-printable

  My motive is not PR.  My motive is very specifically, this:  I would=20
like to have a subversion merge that supports a modern code review=20
workflow.  You commit to a branch, someone else reviews the commit, and=20
merges it into a shared build.  If I can add that to my app, it helps=20
all of my svn users run a more scalable process.

There are many apps, including my own, that implement this workflow with =

git, etc.  It's not possible now with subversion, because subversion=20
merge doesn't work well, except under special circumstances.  Someone=20
needs to stand up and say:  "This is an ugly baby".

How did the baby get ugly?  It's obvious.  There are too many=20
constraints.  You can't get a good merge when you are handling mixed=20
revisions and subtree merges with skeletal merginfo.  You can't do it. =20
So, a bunch of very smart, very dedicated people are having a hard time=20
delivering a good merge.

Those smart and dedicated people, including Julian, and including you,=20
should be freed up to do something that actually works.

The migration path is simple.  If you use all of the features of the old =

merge, use the old merge.  If you want to use a different merge that=20
doesn't like your old repository, make a clean branch with a clean=20
current version, and start using the different merge.

It also seems clear that an open source project needs to give=20
contributors room to contribute.  git merge has 5 different merge=20
"strategies".  People plug in new ones when they need new ones.  That=20
would work for subversion.

On 4/17/2012 2:29 PM, Branko =C4=8Cibej wrote:
> On 17.04.2012 18:40, Andy Singleton wrote:
>>   It sounds like there is a clear choice for the first release of
>> Julian's Symmetric Merge project:
>> 1) Add "symmerge" as a new command and leave the existing merge in pla=
ce,
>> 2) or try to replace the existing merge in one shot for all existing
>> users.
> This sound suspiciously like Assembla's "newmerge" pitch all over again=
=2E
> I'll refrain from commenting on the technical merits of such an idea,
> only to note that I'll veto any solution that a) perpetuates the state
> where the users have to deal with two different merge algorithms, and/o=
r
> b) creates a state of affairs when some forms of merges that are valid
> today become suddenly invalid, or broken, with a new release of Subvers=
ion.
>
>> If you asked me to try to replace all of the options and behaviors in
>> the existing merge, I would say that it is a daunting task that will
>> create delays.  I would never take that as a deliverable for a agile
>> project.
> Delays to whose schedule? You'll have to get it into your head that thi=
s
> project does not live by some corporate buff's idea of schedule and agi=
le.
>
>>    I would build a new merge command that handles as much as possible
>> of the workflow that we are trying to fix - sync and keepalive for
>> trunk and feature branches.
> No. That is /not/ the purpose of the symmetric merge project. Its
> purpose is to make "svn merge" work correctly in all circumstances that=

> can arise from the effects of "svn merge" as it exists today.
> Specifically, to do away with the need for the --reintegrate option, an=
d
> to give the same or better results. There's not much slack here except
> for the "or better" part, but that pretty much has to be an implicit
> result of using a correct merge algorithm.
>
> Unless you can come up with a simpler plan that does not screw up
> people's existing repositories.
>
>>    I would have it halt politely if it found a case it didn't like, an=
d
>> I would definitely include subtree merginfo and mixed revisions in
>> cases that I don't like.
> And tell what to users? "Sorry, you can't merge this because covering
> this case wasn't mentioned in my schedule, and the problem was too hard=

> to solve in a 10-minute Monday morning scrum?"
>
>>    Then, I would exploit the new merge to implement modern code review=

>> workflows - including a replacement for the emailed patches on this li=
st.
>>
>> I would also use the new merge command as a documented template for
>> anyone who wanted to implement a different merge algorithm, and I
>> would open it up for contributions with some bounty rewards.  You
>> can't do that if you are trying to cram everything into one merge comm=
and.
> Oh give me a break. How many merge commands do other version control
> systems have? One for each scrum target?
>
>
> All this may sound harsh and unrestrained, but I've had a bellyful of
> how certain parties continue to try to subvert this project for a
> junkload of PR and newspeak jibberish and will not stand idly by and le=
t
> it happen again.
>
>
> -- Brane
>
> P.S.: I can't wait for someone to explain how you do the hard bits of,
> e.g., a C++ compiler in an agile manner. Leave out half the semantics
> and 90% of the standard library, most likely.