news <news@sea.gmane.org> wrote on 07/31/2006 08:49:37 PM:
> Mark Phippard wrote:
> > My point being that you are going to run into this problem no matter
what
> > we do because that is how Subversion works and we cannot issue an
update
> > after every commit. Adding an update at the end of Share Project just
> > does not seem like it is really fixing anything.
>
> I think that we may have an improvement for Subversion here. As you
> might know, I have a ClearCase background. ;) We have the exact same
> problem with ClearCase Snapshot views. Basically, a directory is
> modified whenever you add, remove oder rename a file in it. If your
> Snapshot view was not at HEAD (i.e. LATEST) when you made the
> modification you got the same problem on commit (i.e. check-in).
>
> However, ClearCase is a little bit more user friendly in that case.
> Instead quiting with an unhelpful error message it brought up the Merge
> Manager to merge the change with the LATEST version of the directory and
> check-in thereafter.
>
> Mark, do you see any chance that this can happen in Subclipse and/or any
> other Subversion client?
In a multi-user scenario, if you use the Synchronize view and realize that
you should do Update before Commit, you can pretty well avoid it.
Subclipse has a problem in the single user scenario in that we do not have
a facility for showing out of date folders in the Synch view. Although in
that scenario, I think it would still be pretty confusing to need to do an
update.
Also keep in mind that this error only appears if you attempt to modify
the properties on a folder, or delete/rename a child in the folder. So a
lot of users could go a long time before they ever get it.
> Would it be possible to catch this error in a Subversion client and
> update just the directory object to HEAD (without updating it
> recursively), merge the change and commit (if the commit is plausible)?
The proposal I have made to the Subversion developers is to enhance commit
so that it can keep the folders up to date automatically in more cases. If
you commit revision N and the parent folder revision is N-1, the commit
process ought to be able to update the folder in the working copy to
revision N safely. If this were added to Subversion it would lessen the
problem scenario (single users would never get a problem). We could
potentially add this in to Subclipse even if Subversion does not, but we
could only do it by issuing the svn update command which would be a lot
slower than something that just updated the metadata. If I get a
favorable response to the idea, I will look into whether it is feasible to
add this to Subversion so we can try to get it into 1.5.
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subclipse.tigris.org
For additional commands, e-mail: users-help@subclipse.tigris.org
Received on Tue Aug 1 03:10:23 2006