rooneg@gmail.com wrote on 08/01/2006 10:26:50 AM:
> On 7/31/06, David James <djames@collab.net> wrote:
> > On 7/31/06, Mark Phippard <markp@softlanding.com> wrote:
> > > Over on the Subclipse list (I also see this on users@ and
TortoiseSVN
> > > lists) we have been getting a lot of activity from new users that
are
> > > really confused by the out of date errors they get. I think we see
this a
> > > lot more in Subclipse because the Eclipse IDE encourages refactoring
which
> > > leads to a lot of moves and renames.
> > >
> > > The biggest problem we run into is with new users working alone with
a
> > > repository. It is easy to understand how someone with one project
and one
> > > working copy working by themselves can get confused by an error
saying
> > > their project is out of date.
> >
> > Nice analysis, Mark! I wholeheartedly agree that users should not
> > receive an "out of date" error in this scenario. I've seen this
> > problem before and it has also puzzled me. Do you have a reproduction
> > recipe? It'd be great if we could add an XFAIL test for this issue to
> > the Python test suite.
>
> Umm, if I recall correctly there are good reasons why users get out of
> date errors in those cases. It has to do with our mixed revision
> working copy support, and it's there because other ways of doing
> things cause more problems. It's not like we just said "aw hell, lets
> take the easy way out", the alternative is worse. I mean it's not
> like the client and server can say "oh wait, there's only one working
> copy and one user, I can change that behavior"...
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.
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:39:23 2006