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

RE: "svn pget svn:externals -r <rev> . -R" dramatically slow

From: Bert Huijben <bert_at_qqmail.nl>
Date: Mon, 22 May 2017 11:44:36 +0200

> -----Original Message-----
> From: Branko Čibej [mailto:brane_at_apache.org]
> Sent: donderdag 18 mei 2017 15:19
> To: users_at_subversion.apache.org
> Cc: Andrey <andry_at_inbox.ru>
> Subject: Re: "svn pget svn:externals -r <rev> . -R" dramatically slow
>
> On 18.05.2017 13:51, Andrey wrote:
> > Branko Čibej <brane_at_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_at_zulu:~/test/wc$ svn mv foo bar
> A bar
> D foo
> brane_at_zulu:~/test/wc$ echo foo > foo
> brane_at_zulu:~/test/wc$ svn st
> A + bar
> > moved from foo
> D foo
> > moved to bar
> brane_at_zulu:~/test/wc$ svn ci -mm
> Adding bar
> Deleting foo
> Committing transaction...
> Committed revision 2.
> brane_at_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_at_zulu:~/test/wc$ touch qux
> brane_at_zulu:~/test/wc$ svn add qux
> A qux
> brane_at_zulu:~/test/wc$ svn ci -mm
> Adding qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 3.
> brane_at_zulu:~/test/wc$ svn mv qux baz
> A baz
> D qux
> brane_at_zulu:~/test/wc$ echo qux > qux
> brane_at_zulu:~/test/wc$ svn add qux
> A qux
> brane_at_zulu:~/test/wc$ svn st
> A + baz
> > moved from qux
> ? foo
> R qux
> > moved to baz
> brane_at_zulu:~/test/wc$ svn ci -mm
> Adding baz
> Replacing qux
> Transmitting file data .done
> Committing transaction...
> Committed revision 4.
> brane_at_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
Received on 2017-05-22 11:44:45 CEST

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

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