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

Re: Extending new update --force switch to handle local additions -- also new related FAQ

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: 2006-08-24 01:04:02 CEST

Mark Phippard wrote:
> The scenario is that the user contributed a patch to an open source
> project using Subversion. The patch included new files, so he ran svn add
> so that they would be included in the svn diff output. The patch is
> accepted and committed by a committer. The user now runs svn update on
> his working copy and it fails because he still has the new files in his
> working copy. He feels that update should handle this.

Yes, and more. Since we automatically resolve text modifications when the
local change is identical to the repository change, I say we ought to
automatically resolve identical tree operations - add/delete/move file/dir.

> Paul Burba's recent patch added --force option to update. If the file was
> in an unversioned status in his working copy, and he used this option,
> then update would handle the situation. I think we should consider
> extending this feature to do the same thing if the file was a scheduled
> add in his working copy.

It shouldn't need "force". It should just be part of our normal behaviour that
we merge identical changes in the obvious trivial way. Is there any possible
difficulty with this? (There is the chance that this is not the semantically
correct merge in some cases, but that applies equally to text changes and to
tree changes.)

> Would it be OK if I enter an issue for this in the issue tracker?

Certainly - please do.

(I have not looked at your FAQ. (It didn't show up as text in my mail client.)
  I'm sure if it says anything useful at all then it is better to have it than
not to have it.)

- Julian

To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Aug 24 01:03:03 2006

This is an archived mail posted to the Subversion Dev mailing list.

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