You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Eichin <ei...@gmail.com> on 2011/08/16 23:54:57 UTC
svn cross-repo copy loses svn:executable *and* leaves the working dir inconsistent
Ran across this while writing a "populate new repo" script, that used
svn cp to copy a set of svn-hooks in place (by definition from one
repo to another.) What happens is that when a file in the source repo
(called "foreign" here) has svn:executable set, the working dir in the
destination (called "local" here) looks right - ls -l shows the +x
bits, svn proplist -v shows the property, even .svn/props-base
mentions it. The commit, on the other hand, doesn't push it to the
repository. This means that the local checkout is now a "persistent
lie" (in that trying to set it there and commit it does nothing,
because it's "already" set.) A fresh checkout of the result shows the
bits missing, though.
I'm doing copy from url to working dir because in practice, I need to
do some variable substitution before pushing the file to the new repo;
that substitution isn't in the script because without it, the bug
still happens.
I've only tested this on "svn, version 1.6.12 (r955767) - compiled Jun
5 2011, 14:55:20" which is 1.6.12dfsg-1ubuntu1.3 from Ubuntu 10.10
(maverick.) Also, while the test is between two locally built repos
with file:// urls, I originally saw the problem going between https://
and svn+ssh:// which distracted me :-) So I'd appreciate if people
who can conveniently do so would test this on newer versions. Thanks.
#!/bin/sh -e
################################################
LOCAL_REPO_DIR=/tmp/svn-propcopy-repo-local
FOREIGN_REPO_DIR=/tmp/svn-propcopy-repo-foreign
PREP_FOREIGN_WORKDIR=/tmp/svn-propcopy-work-prep
PERFORM_COPY_WORKDIR=/tmp/svn-propcopy-work-copy
SHOW_FAILURE_WORKDIR=/tmp/svn-propcopy-work-show
rm -rf $LOCAL_REPO_DIR
rm -rf $FOREIGN_REPO_DIR
rm -rf $PREP_FOREIGN_WORKDIR; mkdir -p $PREP_FOREIGN_WORKDIR
rm -rf $PERFORM_COPY_WORKDIR; mkdir -p $PERFORM_COPY_WORKDIR
rm -rf $SHOW_FAILURE_WORKDIR; mkdir -p $SHOW_FAILURE_WORKDIR
################################################
echo ==== create two repos: one local, ====
svnadmin create $LOCAL_REPO_DIR
LOCAL_REPO=file:////$LOCAL_REPO_DIR
svn mkdir -m 'trunk' $LOCAL_REPO/trunk
svn mkdir -m 'branch' $LOCAL_REPO/branch
echo ==== one '"foreign"' ====
svnadmin create $FOREIGN_REPO_DIR
FOREIGN_REPO=file:////$FOREIGN_REPO_DIR
svn mkdir -m 'trunk 2' $FOREIGN_REPO/trunk
svn mkdir -m 'branch 2' $FOREIGN_REPO/branch
################################################
echo ==== Create an executable file in the foreign repo. ====
svn co $FOREIGN_REPO/trunk $PREP_FOREIGN_WORKDIR/trunk
cat > $PREP_FOREIGN_WORKDIR/trunk/program <<EOF
#!/bin/sh
echo running 1
EOF
svn add $PREP_FOREIGN_WORKDIR/trunk/program
svn propset svn:executable '*' $PREP_FOREIGN_WORKDIR/trunk/program
svn commit -m 'committed a file' $PREP_FOREIGN_WORKDIR/trunk
################################################
echo ==== Copy the executable from the foreign repo to the local one. ====
svn co $LOCAL_REPO/branch $PERFORM_COPY_WORKDIR/branch
svn copy $FOREIGN_REPO/trunk/program $PERFORM_COPY_WORKDIR/branch/copied-program
ls -l $PERFORM_COPY_WORKDIR/branch
svn commit -m 'copied program' $PERFORM_COPY_WORKDIR/branch
svn proplist -vR $PERFORM_COPY_WORKDIR/branch
echo ==== Notice that copied-program still has +x set, and the
property set... ====
################################################
echo ==== Now check out the local tree and see that we''ve lost the props. ====
svn co $LOCAL_REPO/branch $SHOW_FAILURE_WORKDIR/branch
ls -l $SHOW_FAILURE_WORKDIR/branch
svn proplist -vR $SHOW_FAILURE_WORKDIR/branch
svn --version
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
RE: svn cross-repo copy loses svn:executable *and* leaves the working dir inconsistent
Posted by Bert Huijben <be...@qqmail.nl>.
> -----Original Message-----
> From: Daniel Shahaf [mailto:d.s@daniel.shahaf.name]
> Sent: woensdag 17 augustus 2011 0:22
> To: Mark Eichin
> Cc: dev@subversion.apache.org
> Subject: Re: svn cross-repo copy loses svn:executable *and* leaves the
> working dir inconsistent
>
> I can reproduce this with trunk.
>
> Mark Eichin wrote on Tue, Aug 16, 2011 at 17:54:57 -0400:
> > Ran across this while writing a "populate new repo" script, that used
> > svn cp to copy a set of svn-hooks in place (by definition from one
> > repo to another.) What happens is that when a file in the source repo
> > (called "foreign" here) has svn:executable set, the working dir in the
> > destination (called "local" here) looks right - ls -l shows the +x
> > bits, svn proplist -v shows the property, even .svn/props-base
> > mentions it. The commit, on the other hand, doesn't push it to the
> > repository. This means that the local checkout is now a "persistent
> > lie" (in that trying to set it there and commit it does nothing,
> > because it's "already" set.)
>
> So, it's definitely a bug *somewhere*.
.svn/props-base shouldn't have any properties on a cross-repo copy/merge.
And that there are pristine properties for a local addition also explains
why the property changes aren't pushed on commit: the working copy doesn't
see them as changes.
> > svn co $LOCAL_REPO/branch $PERFORM_COPY_WORKDIR/branch
> > svn copy $FOREIGN_REPO/trunk/program
> $PERFORM_COPY_WORKDIR/branch/copied-program
>
> Is this documented to work?
Bert
Re: svn cross-repo copy loses svn:executable *and* leaves the working
dir inconsistent
Posted by "C. Michael Pilato" <cm...@collab.net>.
http://subversion.tigris.org/issues/show_bug.cgi?id=3590 documents some of
the history of this action (copy from a foreign repository). I have no idea
how 1.7 behaves in this same scenario, though I don't recall anyone
intentionally targeting this functionality.
That said, as it was me that filed that above issue, I'm clearly in favor of
allowing this sort of operation -- especially if it can preserve all the
node properties as part of the copy, too. I see this as very beneficial to
bootstrapping a foreign-repository-based vendor branch situation.
As for the text of the 1.6 book, I'm mostly responsible for that, too, and I
can tell you that I didn't re-test Subversion's behavior in this regard when
working on that version of the text. If the book is inaccurate, please send
a patch (or at least a notice of the problem) to svnbook-dev@red-bean.com.
On 08/29/2011 03:42 AM, Mark Eichin wrote:
> The 1.6 book has the same Note text, as does
> http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.copy.html - so at
> least it hasn't been documented any differently in that time. (So it
> at least appears that cross-repo cherry-picking isn't an
> intentionally-supported use case...)
>
> On Mon, Aug 22, 2011 at 2:25 PM, Hyrum K Wright
> <hy...@wandisco.com> wrote:
>> That text is from the 1.5 section of the book. 1.5 is over 4 years
>> old, so current behavior might be different...
>>
>> On Sun, Aug 21, 2011 at 8:48 PM, Mark Eichin <ei...@gmail.com> wrote:
>>> Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.copy.html
>>> actually has a Note:
>>> "You can only copy files within a single repository. Subversion does
>>> not support cross-repository copying."
>>>
>>> I guess that means that the bug is that it doesn't check uuids and
>>> actually *enforce* this; I'm sure I'm not the only one who'd be
>>> surprised to learn of this constraint - especially since merge doesn't
>>> have such a warning (and in fact cross-repo cherry-picking with svn
>>> merge is actually kind of important...)
>>>
>>>
>>>
>>> --
>>> _Mark_ <ei...@thok.org> <ei...@gmail.com>
>>>
>>
>>
>>
>> --
>>
>> uberSVN: Apache Subversion Made Easy
>> http://www.uberSVN.com/
>>
>
>
>
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: svn cross-repo copy loses svn:executable *and* leaves the working
dir inconsistent
Posted by Mark Eichin <ei...@gmail.com>.
The 1.6 book has the same Note text, as does
http://svnbook.red-bean.com/nightly/en/svn.ref.svn.c.copy.html - so at
least it hasn't been documented any differently in that time. (So it
at least appears that cross-repo cherry-picking isn't an
intentionally-supported use case...)
On Mon, Aug 22, 2011 at 2:25 PM, Hyrum K Wright
<hy...@wandisco.com> wrote:
> That text is from the 1.5 section of the book. 1.5 is over 4 years
> old, so current behavior might be different...
>
> On Sun, Aug 21, 2011 at 8:48 PM, Mark Eichin <ei...@gmail.com> wrote:
>> Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.copy.html
>> actually has a Note:
>> "You can only copy files within a single repository. Subversion does
>> not support cross-repository copying."
>>
>> I guess that means that the bug is that it doesn't check uuids and
>> actually *enforce* this; I'm sure I'm not the only one who'd be
>> surprised to learn of this constraint - especially since merge doesn't
>> have such a warning (and in fact cross-repo cherry-picking with svn
>> merge is actually kind of important...)
>>
>>
>>
>> --
>> _Mark_ <ei...@thok.org> <ei...@gmail.com>
>>
>
>
>
> --
>
> uberSVN: Apache Subversion Made Easy
> http://www.uberSVN.com/
>
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
Re: svn cross-repo copy loses svn:executable *and* leaves the working
dir inconsistent
Posted by Hyrum K Wright <hy...@wandisco.com>.
That text is from the 1.5 section of the book. 1.5 is over 4 years
old, so current behavior might be different...
On Sun, Aug 21, 2011 at 8:48 PM, Mark Eichin <ei...@gmail.com> wrote:
> Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.copy.html
> actually has a Note:
> "You can only copy files within a single repository. Subversion does
> not support cross-repository copying."
>
> I guess that means that the bug is that it doesn't check uuids and
> actually *enforce* this; I'm sure I'm not the only one who'd be
> surprised to learn of this constraint - especially since merge doesn't
> have such a warning (and in fact cross-repo cherry-picking with svn
> merge is actually kind of important...)
>
>
>
> --
> _Mark_ <ei...@thok.org> <ei...@gmail.com>
>
--
uberSVN: Apache Subversion Made Easy
http://www.uberSVN.com/
Re: svn cross-repo copy loses svn:executable *and* leaves the working
dir inconsistent
Posted by Mark Eichin <ei...@gmail.com>.
Huh. http://svnbook.red-bean.com/en/1.5/svn.ref.svn.c.copy.html
actually has a Note:
"You can only copy files within a single repository. Subversion does
not support cross-repository copying."
I guess that means that the bug is that it doesn't check uuids and
actually *enforce* this; I'm sure I'm not the only one who'd be
surprised to learn of this constraint - especially since merge doesn't
have such a warning (and in fact cross-repo cherry-picking with svn
merge is actually kind of important...)
--
_Mark_ <ei...@thok.org> <ei...@gmail.com>
Re: svn cross-repo copy loses svn:executable *and* leaves the
working dir inconsistent
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
I can reproduce this with trunk.
Mark Eichin wrote on Tue, Aug 16, 2011 at 17:54:57 -0400:
> Ran across this while writing a "populate new repo" script, that used
> svn cp to copy a set of svn-hooks in place (by definition from one
> repo to another.) What happens is that when a file in the source repo
> (called "foreign" here) has svn:executable set, the working dir in the
> destination (called "local" here) looks right - ls -l shows the +x
> bits, svn proplist -v shows the property, even .svn/props-base
> mentions it. The commit, on the other hand, doesn't push it to the
> repository. This means that the local checkout is now a "persistent
> lie" (in that trying to set it there and commit it does nothing,
> because it's "already" set.)
So, it's definitely a bug *somewhere*.
> svn co $LOCAL_REPO/branch $PERFORM_COPY_WORKDIR/branch
> svn copy $FOREIGN_REPO/trunk/program $PERFORM_COPY_WORKDIR/branch/copied-program
Is this documented to work?