[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Properties (was Re: Subversion Vision and Roadmap Proposal)

From: Martin Hauner <martin.hauner_at_gmx.net>
Date: Fri, 09 Apr 2010 20:58:19 +0200

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.
Received on 2010-04-08 20:59:05 CEST

This is an archived mail posted to the Subversion Dev mailing list.