Hi,
On 05.04.10 17:06, Stefan Sperling wrote:
On Mon, Apr 05, 2010 at 04:14:21PM +0200, Martin Hauner wrote:
[..]
In case of merging (mostly cherry picking from trunk to live and
next release branches, merge tracking is nice BUT svn:merginfo on
the root folder kills it again. After each merge I have to update
again (ie. wait another few minutes) before I'm able to commit
again.
So mergeinfo kills it because it takes a long time to update?
How is this any different from the performance problem you mentioned,
and what has it got to do with mergeinfo?
Or do you generally oppose the idea of storing merge information
in svn: properties? If so, were else would you store it?
Äh, performance yes. ;-)
The performance problem makes merge tracking more a pain than a gain.
Before merge tracking I could do this:
merge (cherry pick) from trunk to branch
commit, add merged revision to log message
merge (cherry pick) from trunk to branch
commit, add merged revision to log message
and so on...
In most cases this didn't touch common folders so while updating my branch I
could mostly skip the update step.
With svn:mergeinfo I have to update after each commit because its on my root
folder and always is out of date on the next commit. So the extra step takes
away another few minutes because of the performance issue.
merge (cherry pick) from trunk to branch
commit
update
merge (cherry pick) from trunk to branch
commit
update
This is annoying.. :)
So yes, apart from the performance issue I don't like that svn:merginfo is a
property on the root folder. Using a property for this kind of information feels
wrong to me.
You mention that there is the idea of using another svn: property to configure
branching/merging strategy. I don't like that either.
I see that looking from the "how do we get this into subversion" point of view
properties are an option because we don't have a better place. But from a user
point of view this is completely arcane.
This is "high level" info or meta information and not interesting for single
files & folders. Having them user visible at "special" places (i.e. the root
folder, which it is only by convention) or "normal" files & folders is confusing.
In case of svn:mergeinfo on the root folder it even interferes with the normal
work flow. On /trunk I can commit without update for a while. On cherry picking
& merging I always have to commit & update.
So as a user I ask: why is this two steps then..? What a strange system ;-)))
I can't offer a better place to store such information, but in my opinion it
shows that subversion is missing something, a basic concept, here.
Some random thoughts:
Maybe such configuration could be stored in global properties? Properties not
set on files/folders or revisions but on the repository.
From an svn client view, I would like to have api calls to get all interesting
info (for example the repository layout) for any given repository location.
svn_client_get_root
("http://svn.apache.org/repos/asf/subversion/trunk/subversion/svn_client";);
would give me "http://svn.apache.org/repos/asf/subversion/trunk";
svn_client_get_root
("http://svn.apache.org/repos/asf/subversion/branches/1.6.x/subversion/svn_client";);
would give me "http://svn.apache.org/repos/asf/subversion/branches/1.6.x";
Then I could ask
svn_client_layout ("http://svn.apache.org/repos/asf/subversion/trunk";);
or
svn_client_layout ("http://svn.apache.org/repos/asf/subversion/branches/1.6.x";);
which would tell me
trunk: "http://svn.apache.org/repos/asf/subversion/trunk";
branches: "http://svn.apache.org/repos/asf/subversion/branches";
tags: "http://svn.apache.org/repos/asf/subversion/tags";
Then an "svn branch" could check that the target is indeed in branches and not
tags.
Thanks,
Stefan
--
Martin
Subcommander 2.0.0 Beta 5 - http://subcommander.tigris.org
a Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
