Re: merge logs

Nick Thompson <nickthompson@agere.com> writes:
> I've read much about the ideas for merge nirvana that are on the SVN
> road map and it looks like there is lots to do. It looks like fixing
> up renaming is the first on the list.
>
> But looking from the outside in, what about adding some kind of merge
> logs to the repository as a relative priority? For my purposes
> svnmerge looks like a good improvement over standard svn merge, but
> its a shame that the way it records merges is probably not compatible
> with any future solution. If merge logs where added to svn base, then
> add-on tools like svnmege could make use of them today, "best
> practices" that require non-expert users to remember to write a sane
> log entry for a merge could be relaxed, and merges initiated from GUIs
> would be captured, all in a compatible way. A way to list these merge
> logs would of course be required as well. This might even meet some
> group's requirement for merge tracking, in that it is at least
> formally recorded and manually traceable.
>
> This step, I guess, should be fairly easy to scope and provide good
> extra features. It will also allow developers who don't want to fiddle
> with repository formats to start looking at improving merge so as to
> start moving along the roadmap to that distant nirvana.
>
> Just and outsider looking in, Thanks for listening,

Here's something I just wrote about another proposal:

 | Well, my initial reaction is: neat idea, but this specification barely
 | scratches the tip of the beak of a penguin standing on the tip of the
 | iceberg. Designing such a feature would require a lot of discussion &
 | thought; it will turn out to be made almost entirely of edge cases. I
 | personally don't have time to work on it, unfortunately. If you can
 | find developers who do, then it may go somewhere. But please note
 | that there are always hundreds of ideas floating around. Most will
 | never get implemented. It's not because they're bad, it's just
 | because there are always more ideas than hands and heads to code them.

I think it applies here too, even more so in fact.

This would not be easy to scope at all. Whatever those merge logs
are, once they enter our APIs, we must support them forever (well, at
least until 2.0, and even then we don't want to toss things unless we
absolutely must -- compatibility is an obsession around here).

So, that means we'd have to design them very carefully, making sure
that they can efficiently express everything they might need to
express. If you think about this, you will see that it is equivalent
to designing merge tracking in the first place.

If coming up with universally useful merge logs were easy, then
svnmerge would have done so, and you wouldn't be worried about its
logs not being compatible with whatever Subversion comes up with in
the future. As it is, you are right to worry, but this is not because
svnmerge has done anything wrong; it's because it's a hard, hard
problem.

-Karl

-- 
www.collab.net  <>  CollabNet  |  Distributed Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org