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?
-garrett
---------------------------------------------------------------------
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:38:26 2006