james82@gmail.com wrote on 07/31/2006 06:08:22 PM:
> 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.
I will work with Paul Burba to see if we can come up with a Python test. I
can tell you the process that happens within Subclipse though.
Scenario is that user has an Eclipse project that they want to "Share"
with Subversion. They take an option to do so and we:
1) Use svn mkdir to create a folder for the project in the repository.
2) Checkout that empty folder on top of the Eclipse project folder
(turning it into a working copy)
3) At this point, let's say the root project folder is at r1.
4) Commit dialog lets user svn add and then commit all of the files and
folders.
5) At this point, the root project folder will still be at r1, and all
other files and folders will be at r2.
6) User adds "bin" folder to svn:ignore property of root project folder
and commits.
7) Commit fails because root is out of date.
Step 6 could have also been a rename of a child folder or file of the root
as well. And of course if this were a single user project, the user could
have modified many files and done many commits before running into this.
It is still confusing because it does not make sense to them they should
have to have done an update.
There are a lot of scenarios that can produce this error, and many of them
are perfectly legit, meaning yes the user should have to do an update. But
there are plenty of scenarios where Subversion could be doing a better job
for the user by silently updating folder revisions in the working copy
when it can, such as the N-1 scenario I originally described.
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 02:45:27 2006