Re: merge logs
From: <kfogel_at_collab.net>
Date: 2005-09-20 22:51:00 CEST
I think what this boils down to is, you're saying "Can we please start
And I'm responding "Well, I'd like to, but I personally don't have the
I wish I could give you the answer you really wanted to hear, but I
Best,
-- www.collab.net <> CollabNet | Distributed Development On Demand Nick Thompson <nickthompson@agere.com> writes: > 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 -- --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org For additional commands, e-mail: dev-help@subversion.tigris.orgReceived on Tue Sep 20 23:59:44 2005 |
This is an archived mail posted to the Subversion Dev mailing list.
This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.