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

[Ben Collins-Sussman <su...@collab.net>]

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

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

[Guillaume Boissiere <bo...@media.mit.edu>]

> > + 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 agree that there is an extra bit of information you lose by
using U so you successfully convinced me it should be marked as R, 
not U.

I think there is a case to be made to make U = R in a Subversion 
GUI client that tries to keep things simple for the users, and 
not in Subversion itself.  But that's another story...

 
> > + 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'.
> 

Agreed.  Thanks for your quick response!

-- Guillaume



---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org