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

RE: disallow mixed-revision WC->{WC,URL} copies by default?

From: Bert Huijben <bert_at_qqmail.nl>
Date: Thu, 9 Feb 2012 20:52:34 +0100

> -----Original Message-----
> From: Stefan Sperling [mailto:stsp_at_elego.de]
> Sent: donderdag 9 februari 2012 20:34
> To: dev_at_subversion.apache.org
> Subject: disallow mixed-revision WC->{WC,URL} copies by default?
>
> Recently we had a user in #svn who somehow managed to create a
> copy that could not be committed because of out-of-dateness errors.
>
> I am not exactly sure what the real cause of the problem was.
> It could be worked around by using a URL as copy source. So it
> is likely that mixed-revisionnes somehow interfered the commit.
>
> It was pointed out that novice users may not realise that they
> might be copying mixed-revision trees if they run
> svn copy DIR1 DIR2
> in their working copy. Of course, mixed-revisions are explained
> in chapter 2 of the book and should be considered basic knowledge.
> But because mixed-revisionness is hard to notice (nothing except
> 'svn info' shows it), users often simply forget about it.
>
> We added the --allow-mixed-revisions option to 'svn merge' in 1.7.
> Would it make sense to make 'svn copy' require this option if the
> copy source is a mixed-rev WC subtree, in 1.8?
> This would make sure that WC->{WC,URL} copies produce, by default,
> the same result as URL->URL copies (modulo local mods in the WC).

Wouldn't this break most existing scripts that use 'svn cp'?

I know we did the same thing for merge, but you could never be sure if a
merge makes sense without looking at more details anyway, but in all
versions of Subversion 'svn cp' just works from every undeleted node in the
working copy, while this in this case it would break on almost every working
copy directory where something is committed from.

        Bert
Received on 2012-02-09 20:53:12 CET

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.