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

Re: Reducing "out-of-date" errors

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-08-01 16:54:00 CEST

rooneg@gmail.com wrote on 08/01/2006 10:36:48 AM:

> On 8/1/06, Mark Phippard <markp@softlanding.com> wrote:
>
> > There is no question that this is the case and that the current
behavior
> > is right. The question I am raising is whether there are scenarios
where
> > the current behavior could still be refined to make the experience
better.
> > If I checkout repository at r100, so my entire working copy is at
r100.
> > If I then do a commit of some files and the new revision comes back as
> > r101. Then just as an example, in this scenario Subversion could
> > theoretically update the folders in the working copy to r101. If I
had
> > committed r102, then it couldn't safely do this and would not try to.
> >
> > There might be better ways to do this, it was just an idea. It does
not
> > remove the issue altogether but it could make the user experience
better
> > for a some scenarios.
> >
> > One thing is clear, in a standard multiple developer scenario with a
> > variety of commits happening from multiple sources, then the current
> > behavior is correct and probably cannot really be improved much. I am
not
> > suggesting that Subversion is broken or took a short cut.
>
> Well, the "we only bumped by one, lets increment everything" case may
> simplify things, but as soon as people have tags or branches or
> anything beyond the utterly trivial case of one working copy and one
> project they're still going to hit the problem, should we add
> complexity to the codebase just to help a case that happens virtually
> never?

I do not know, that is why I asked. I think it would help, and it goes a
little beyond this trivial use case. You could have done an
update/checkout so that you were at HEAD, then done a commit, now you want
to do a rename or property set. If it so happened that there had not been
other activity on your project, then that last commit would have kept your
folders up to date and you could perform the operation without an update.

Another possibility, but I suspect it would be an even bigger change would
be to be less agressive about bumping folder revisions. As I understand
it, if I modify a file and commit it, the parent folder (or is it all
parent folders) has its revision bumped. I think that some other tools
that manage folders would only do it when files are added/deleted or the
folder properties are changed.

Mark

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Aug 1 16:56:45 2006

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.