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

Re: [Subclipse-users] 1.1.4: Merge conflict during commit in freshly shared project

From: Mark Phippard <markp_at_softlanding.com>
Date: 2006-08-01 03:10:09 CEST

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
> > we do because that is how Subversion works and we cannot issue an
> > 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

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.


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

This is an archived mail posted to the Subclipse Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.