subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bert Huijben" <b...@qqmail.nl>
Subject RE: "svn pget svn:externals -r <rev> . -R" dramatically slow
Date Mon, 22 May 2017 09:44:36 GMT


> -----Original Message-----
> From: Branko Čibej [mailto:brane@apache.org]
> Sent: donderdag 18 mei 2017 15:19
> To: users@subversion.apache.org
> Cc: Andrey <andry@inbox.ru>
> Subject: Re: "svn pget svn:externals -r <rev> . -R" dramatically slow
> 
> On 18.05.2017 13:51, Andrey wrote:
> > Branko Čibej <brane@apache.org> писал(а) в своём письме
Thu, 18 May
> > 2017 14:41:17 +0300:
> >
> >>> However, I don't want to revert anything, i am talking about
> >>> possibility of forget to add files because they are obscured by the
> >>> deletion state in the status.
> >>
> >> So what do you suggest we do instead?
> >>
> >> There's a file named 'foo' that was deleted with 'svn rm' but not
> >> committed, and also a file named 'foo' that you created on disk before
> >> committing the deletion (or rename). What do you propose  'svn status'
> >> should show?
> > may be add file content hash to represent 2 statuses of the same file
> > paths? At least it will protect file from accidental remove and miss
> > of add to commit?
> 
> There will be no accidental remove; when you commit, your new file will
> remain unversioned in the working copy:
> 
> brane@zulu:~/test/wc$ svn mv foo bar
> A         bar
> D         foo
> brane@zulu:~/test/wc$ echo foo > foo
> brane@zulu:~/test/wc$ svn st
> A  +    bar
>         > moved from foo
> D       foo
>         > moved to bar
> brane@zulu:~/test/wc$ svn ci -mm
> Adding         bar
> Deleting       foo
> Committing transaction...
> Committed revision 2.
> brane@zulu:~/test/wc$ svn st
> ?       foo
> 
> So far, this is what you reported. Now see what happens when you
> actually run 'svn add' to replace the deleted file:
> 
> brane@zulu:~/test/wc$ touch qux
> brane@zulu:~/test/wc$ svn add qux
> A         qux
> brane@zulu:~/test/wc$ svn ci -mm
> Adding         qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 3.
> brane@zulu:~/test/wc$ svn mv qux baz
> A         baz
> D         qux
> brane@zulu:~/test/wc$ echo qux > qux
> brane@zulu:~/test/wc$ svn add qux
> A         qux
> brane@zulu:~/test/wc$ svn st
> A  +    baz
>         > moved from qux
> ?       foo
> R       qux
>         > moved to baz
> brane@zulu:~/test/wc$ svn ci -mm
> Adding         baz
> Replacing      qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 4.
> brane@zulu:~/test/wc$ svn st
> ?       foo
> 
> 
> In the first case, I suppose we could display something like the following:
> 
> D  +    foo
>         > moved to bar
> 
> or:
> 
> D  ?    foo
>         > moved to bar
> 
> 
> to indicate that the file was deleted, but still exists on disk.
> 
> The more interesting question is how, if at all, this would affect the
> Subversion API.

The api already has this information, as there is some on-disk info in the status api that
isn't reported by 'svn' (but is used by other clients).

Note that 'svn rm --keep-local Q' is the only thing necessary to trigger this case. And before
1.7 (pre WC-NG) we always had to keep deleted directories until after they were committed,
but we didn't want to report these as still existing. That is probably why nobody bothered
adding UI for this to 'svn' yet.


	Bert


Mime
View raw message