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

Re: [Issue 571] New - svn update: D+A = U

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2001-11-29 18:29:22 CET

issues@subversion.tigris.org writes:

> + Running 'svn update' produced a list that had the same file twice, once as
> + deleted (D) and once as add (A).
> +
> + svn update subversion
> + [...]
> + D subversion/www/project_faq.html
> + A subversion/www/project_faq.html
> + [...]
> +
> + Shouldn't the appropriate behavior be to mark the file as Updated (U) instead?
> +
> + From a user standpoint, it does not matter what happened to the file between
> + the 2 revisions, and how many times it was deleted / added. The important
> + thing is that in the end this file is not exactly the same as was it was
> + before, even if the content of the file per se is identical.

I think seeing a delete and add is useful to the user, because it
tells the user that it's truly a *new* file; a 'U' would incorrectly
suggest that the old file was simply patched.

> +
> + I saw in the "SVN for CVS users" document that there was also an R option for
> + Replace (= delete then re-add) but my vote would go to just use update, because
> + it's not very clear to me what R brings to the table, and it's yet another
> + option the end user has to remember what it means.

'R' only shows up in 'svn status' on something that is scheduled to be
deleted and re-added. Again, it's useful for the user to know that
they haven't simply (M)odified the file they're planning to commit,
they're completely replacing it.

If anything, I think there's an argument to be made for consistency --
that during an update, an 'R' should be printed instead of a 'D, A'.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:49 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.