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.
