Properties (was Re: Subversion Vision and Roadmap Proposal)

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.