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:29:36 CEST