You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Hauner <ma...@gmx.net> on 2010/04/05 19:28:57 UTC
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.
RE: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Greg Stein [mailto:gstein@gmail.com]
> Sent: donderdag 8 april 2010 22:41
> To: C. Michael Pilato
> Cc: dev@subversion.apache.org
> Subject: Re: Properties (was Re: Subversion Vision and Roadmap
> Proposal)
>
> On Thu, Apr 8, 2010 at 15:35, C. Michael Pilato <cm...@collab.net>
> wrote:
> > Martin Hauner wrote:
> >> Hi,
> >>
> >> On 06.04.10 00:01, Stefan Sperling wrote:
> >>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
> >>>> [..]
> >>>> 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.
> >>>
> >>> The out-of-dateness really comes from the mixed-revision working
> >>> copy concept, not from mergeinfo.
> >>>
> >>> The root of your working copy is not out of date right after
> >>> the commit. It is at the HEAD revision after commit:
> >>>
> >>> $ ls
> >>> alpha beta epsilon/ gamma/
> >>> $ svn merge ^/trunk
> >>> --- Merging r2 through r4 into '.':
> >>> U alpha
> >>> --- Recording mergeinfo for merge of r2 through r4 into '.':
> >>> U .
> >>> $ svn ci -m merge
> >>> Sending .
> >>> Sending alpha
> >>> Transmitting file data .
> >>> Committed revision 5.
> >>> $ svn info . | grep ^Rev
> >>> Revision: 5
> >>>
> >>> Maybe you do not commit the mergeinfo which is set on the root of
> your
> >>> working copy? If so, why not?
> >>
> >> I always commit merges on the root.
> >>
> >> I have tried to create an example, but it works in my test
> repository. I
> >> can't reproduce my "at work" behavior.
> >>
> >> It still complains that '.' is out of date most os the at work. And
> I'm
> >> 100% sure that it started when subversion went merge-tracking.
> >
> > Subversion has always disallowed commits of propchanges on a
> directory
> > that's not fully up to date. Why? For the simple reason that, after
> the
> > commit happens, that directory cannot be considered "at the new
> revision X"
> > because we never got the changes we were missing from the server.
> >
> > What happened with merge tracking is that propchanges on directories
> > suddenly became quite a bit more common. Like ... after every merge.
>
> If there are no propchanges on the directory in the interim, then why
> not allow the commit?
>
> IOW, did we disallow because we were lazy, or is there a fundamental
> problem with allowing the commit to proceed?
We can only do this if there are no property changes on the directory *and*
when there are no children added or removed from the directory.
(This is not necessary an issue on committing, but when we upgrade the
revision number of the directory, without updating the list of children this
list of children is out of date in a way that can't be fixed by updating).
Bert
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by Greg Stein <gs...@gmail.com>.
On Thu, Apr 8, 2010 at 15:35, C. Michael Pilato <cm...@collab.net> wrote:
> Martin Hauner wrote:
>> Hi,
>>
>> On 06.04.10 00:01, Stefan Sperling wrote:
>>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
>>>> [..]
>>>> 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.
>>>
>>> The out-of-dateness really comes from the mixed-revision working
>>> copy concept, not from mergeinfo.
>>>
>>> The root of your working copy is not out of date right after
>>> the commit. It is at the HEAD revision after commit:
>>>
>>> $ ls
>>> alpha beta epsilon/ gamma/
>>> $ svn merge ^/trunk
>>> --- Merging r2 through r4 into '.':
>>> U alpha
>>> --- Recording mergeinfo for merge of r2 through r4 into '.':
>>> U .
>>> $ svn ci -m merge
>>> Sending .
>>> Sending alpha
>>> Transmitting file data .
>>> Committed revision 5.
>>> $ svn info . | grep ^Rev
>>> Revision: 5
>>>
>>> Maybe you do not commit the mergeinfo which is set on the root of your
>>> working copy? If so, why not?
>>
>> I always commit merges on the root.
>>
>> I have tried to create an example, but it works in my test repository. I
>> can't reproduce my "at work" behavior.
>>
>> It still complains that '.' is out of date most os the at work. And I'm
>> 100% sure that it started when subversion went merge-tracking.
>
> Subversion has always disallowed commits of propchanges on a directory
> that's not fully up to date. Why? For the simple reason that, after the
> commit happens, that directory cannot be considered "at the new revision X"
> because we never got the changes we were missing from the server.
>
> What happened with merge tracking is that propchanges on directories
> suddenly became quite a bit more common. Like ... after every merge.
If there are no propchanges on the directory in the interim, then why
not allow the commit?
IOW, did we disallow because we were lazy, or is there a fundamental
problem with allowing the commit to proceed?
Cheers,
-g
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Martin Hauner wrote:
> Hi,
>
> On 06.04.10 00:01, Stefan Sperling wrote:
>> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
>>> [..]
>>> 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.
>>
>> The out-of-dateness really comes from the mixed-revision working
>> copy concept, not from mergeinfo.
>>
>> The root of your working copy is not out of date right after
>> the commit. It is at the HEAD revision after commit:
>>
>> $ ls
>> alpha beta epsilon/ gamma/
>> $ svn merge ^/trunk
>> --- Merging r2 through r4 into '.':
>> U alpha
>> --- Recording mergeinfo for merge of r2 through r4 into '.':
>> U .
>> $ svn ci -m merge
>> Sending .
>> Sending alpha
>> Transmitting file data .
>> Committed revision 5.
>> $ svn info . | grep ^Rev
>> Revision: 5
>>
>> Maybe you do not commit the mergeinfo which is set on the root of your
>> working copy? If so, why not?
>
> I always commit merges on the root.
>
> I have tried to create an example, but it works in my test repository. I
> can't reproduce my "at work" behavior.
>
> It still complains that '.' is out of date most os the at work. And I'm
> 100% sure that it started when subversion went merge-tracking.
Subversion has always disallowed commits of propchanges on a directory
that's not fully up to date. Why? For the simple reason that, after the
commit happens, that directory cannot be considered "at the new revision X"
because we never got the changes we were missing from the server.
What happened with merge tracking is that propchanges on directories
suddenly became quite a bit more common. Like ... after every merge.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by Martin Hauner <ma...@gmx.net>.
Hi,
On 06.04.10 00:01, Stefan Sperling wrote:
> On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
>> [..]
>> 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.
>
> The out-of-dateness really comes from the mixed-revision working
> copy concept, not from mergeinfo.
>
> The root of your working copy is not out of date right after
> the commit. It is at the HEAD revision after commit:
>
> $ ls
> alpha beta epsilon/ gamma/
> $ svn merge ^/trunk
> --- Merging r2 through r4 into '.':
> U alpha
> --- Recording mergeinfo for merge of r2 through r4 into '.':
> U .
> $ svn ci -m merge
> Sending .
> Sending alpha
> Transmitting file data .
> Committed revision 5.
> $ svn info . | grep ^Rev
> Revision: 5
>
> Maybe you do not commit the mergeinfo which is set on the root of your
> working copy? If so, why not?
I always commit merges on the root.
I have tried to create an example, but it works in my test repository. I can't
reproduce my "at work" behavior.
It still complains that '.' is out of date most os the at work. And I'm 100%
sure that it started when subversion went merge-tracking.
I'm heavily confused now. ;-)
> [..]
> We can however improve performance (and we're already working on that).
> So let's assume for a moment that update took 1 nanosecond.
> Would that increase your productivity in an acceptable way, or would
> you still be put off by the fact that you need to run update after commit?
> And is this a big enough problem for your work flow that would make you
> switch to something else for version control?
If it runs fast enough I personally can live with it. No system is perfect :-)
I will not change the system as long as there is nothing that's a lot better
than subversion. Moving from sourcs safe to cvs and from cvs to svn were big
improvements.
But I don't think switching from svn to something else pays off at the moment. I
don't see anything that is way better for what we do at work.
> Thanks,
> Stefan
--
Martin
Subcommander 2.0.0 Beta 5 - http://subcommander.tigris.org
a Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
> 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.
The out-of-dateness really comes from the mixed-revision working
copy concept, not from mergeinfo.
The root of your working copy is not out of date right after
the commit. It is at the HEAD revision after commit:
$ ls
alpha beta epsilon/ gamma/
$ svn merge ^/trunk
--- Merging r2 through r4 into '.':
U alpha
--- Recording mergeinfo for merge of r2 through r4 into '.':
U .
$ svn ci -m merge
Sending .
Sending alpha
Transmitting file data .
Committed revision 5.
$ svn info . | grep ^Rev
Revision: 5
Maybe you do not commit the mergeinfo which is set on the root of your
working copy? If so, why not?
Or maybe you don't realise that you always have a mixed-revision working
copy after a commit?
Even if the root folder is at HEAD, it may be "incomplete" because some
of its children aren't at HEAD yet. So Subversion may not allow you
to commit some of the children (because they really are out of date
and it has to check the repository for new changes and maybe get them,
which is what update is for). So, in general, you need to run svn update
to bring mixed-revision working copies to a single revision.
Of course, if update is so slow that you avoid using it, you will end
up with many of the files and folders in your working copy at different
revisions, and you'll often run into "out of date" errors.
But that still seems to point to the performance problem with update.
So I see several factors which cause the problems for the work flow
you would like to use:
- subversion supports mixed revision working copies, which has
implications on the working copy state after commit, and which
means you should update your entire working copy after every
commit if you want single-revision working copy behavior
- mergeinfo is stored as a property, so it is handled like any other
versioned data, and you need to commit it, causing mixed-revision
working copies
- update is too slow
We can't really toss the mixed-revision working copy concept.
Doing that would force users of busy repositories to update even more often.
And we don't want to let 'svn commit' do an auto-update of the working
copy either. That's the job of 'svn update'.
Changing the way mergeinfo is stored now would be a lot of work,
and we might even use more properties in the future to give users
more control over what Subversion is doing. So properties to manage
meta-data will likely not go away.
We can however improve performance (and we're already working on that).
So let's assume for a moment that update took 1 nanosecond.
Would that increase your productivity in an acceptable way, or would
you still be put off by the fact that you need to run update after commit?
And is this a big enough problem for your work flow that would make you
switch to something else for version control?
Thanks,
Stefan
Re: Properties (was Re: Subversion Vision and Roadmap Proposal)
Posted by Stefan Sperling <st...@elego.de>.
On Mon, Apr 05, 2010 at 07:28:57PM +0200, Martin Hauner wrote:
> 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.
The out-of-dateness really comes from the mixed-revision working
copy concept, not from mergeinfo.
The root of your working copy is not out of date right after
the commit. It is at the HEAD revision after commit:
$ ls
alpha beta epsilon/ gamma/
$ svn merge ^/trunk
--- Merging r2 through r4 into '.':
U alpha
--- Recording mergeinfo for merge of r2 through r4 into '.':
U .
$ svn ci -m merge
Sending .
Sending alpha
Transmitting file data .
Committed revision 5.
$ svn info . | grep ^Rev
Revision: 5
Maybe you do not commit the mergeinfo which is set on the root of your
working copy? If so, why not?
Or maybe you don't realise that you always have a mixed-revision working
copy after a commit?
Even if the root folder is at HEAD, it may be "incomplete" because some
of its children aren't at HEAD yet. So Subversion may not allow you
to commit some of the children (because they really are out of date
and it has to check the repository for new changes and maybe get them,
which is what update is for). So, in general, you need to run svn update
to bring mixed-revision working copies to a single revision.
Of course, if update is so slow that you avoid using it, you will end
up with many of the files and folders in your working copy at different
revisions, and you'll often run into "out of date" errors.
But that still seems to point to the performance problem with update.
So I see several factors which cause the problems for the work flow
you would like to use:
- subversion supports mixed revision working copies, which has
implications on the working copy state after commit, and which
means you should update your entire working copy after every
commit if you want single-revision working copy behavior
- mergeinfo is stored as a property, so it is handled like any other
versioned data, and you need to commit it, causing mixed-revision
working copies
- update is too slow
We can't really toss the mixed-revision working copy concept.
Doing that would force users of busy repositories to update even more often.
And we don't want to let 'svn commit' do an auto-update of the working
copy either. That's the job of 'svn update'.
Changing the way mergeinfo is stored now would be a lot of work,
and we might even use more properties in the future to give users
more control over what Subversion is doing. So properties to manage
meta-data will likely not go away.
We can however improve performance (and we're already working on that).
So let's assume for a moment that update took 1 nanosecond.
Would that increase your productivity in an acceptable way, or would
you still be put off by the fact that you need to run update after commit?
And is this a big enough problem for your work flow that would make you
switch to something else for version control?
Thanks,
Stefan