My motive is not PR. My motive is very specifically, this: I would
like to have a subversion merge that supports a modern code review
workflow. You commit to a branch, someone else reviews the commit, and
merges it into a shared build. If I can add that to my app, it helps
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
merge doesn't work well, except under special circumstances. Someone
needs to stand up and say: "This is an ugly baby".
How did the baby get ugly? It's obvious. There are too many
constraints. You can't get a good merge when you are handling mixed
revisions and subtree merges with skeletal merginfo. You can't do it.
So, a bunch of very smart, very dedicated people are having a hard time
delivering a good merge.
Those smart and dedicated people, including Julian, and including you,
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
doesn't like your old repository, make a clean branch with a clean
current version, and start using the different merge.
It also seems clear that an open source project needs to give
contributors room to contribute. git merge has 5 different merge
"strategies". People plug in new ones when they need new ones. That
would work for subversion.
On 4/17/2012 2:29 PM, Branko Čibej 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 place,
>> 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.
> 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/or
> 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 Subversion.
>
>> 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 this
> project does not live by some corporate buff's idea of schedule and agile.
>
>> 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, and
> 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, and
>> 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 list.
>>
>> 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 command.
> 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 let
> 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.
Received on 2012-04-17 20:51:28 CEST