Re: merge logs

I think svnmerge does a very good job. My only concern about compatibility was
simple the way the merge information is stored, not the content of the
information. If the information required to be stored about merges could be
agreed, and added to the repository as part of the underlying format of the
repository, you can quickly get some benefits that can be further augmented
later, without throwing away todays information. I don't think there is a
perfect solution to this, so I suggest deciding on an approach (albeit for a
medium term plan) and identifying what data is required. I think its a very
small amount of data that is required and easy to identify - but I'm no
expert in Subversion (I'm a ClearCase admin and user).

In the interests furthering the discussion, I thought I would try and
contribute a bit more with the attached txt file. It shows my thoughts from
an svn user perspective. It poses a few questions for svn experts and
proposes a few ideas on what a merge log would contain and how it might be
implemented. I'm happy to work on it a bit more if you have suggestions. (oh
my, its 9KB already)

I know your response was a partial cut and paste, but this one is on the road
map isn't it? Humbly, if its only there to make to roadmap look good, I need
to continue my search.

Hopefully that penguins beak will be feeling the pressure a little more :-)

Best regards,
Nick.

On Tuesday 20 Sep 2005 03:30, kfogel@collab.net wrote:
> 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

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org