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

Re: Svn rename doesn't copy custom properties

From: Branko Čibej <brane_at_wandisco.com>
Date: Fri, 01 May 2015 01:57:49 +0200

On 30.04.2015 23:52, Dan Ellis wrote:
>
>
> On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick <jreedick_at_incomm.com
> <mailto:jreedick_at_incomm.com>> wrote:
>
> > From: Dan Ellis [mailto:danellis10_at_gmail.com <mailto:danellis10_at_gmail.com>]
> >
> > **Brane asked: There's no REN.txt in your example.
> > **Anyway, please tell us which version of the client you're
> using (svn --version) and where it came from.
> >
> > I meant to exclude that as its not relevant, was trying to point
> out the empty response.
> > Sorry everyone, I'm not on the mailing list proper, I'd
> appreciate being cc:d.
> > This is the client version, being whatever was packaged with the
> version of TSVN.
> >
> > svn, version 1.8.9 (r1591380)
> > compiled May 6 2014, 20:28:35 on x86-microsoft-windows
>
> Maybe there's a problem with inherited properties that ignore
> certain files or Something(tm)?
>
> Can you create a new (empty) repo and re-run the test in it?
>
>
>
> I've tried, though only using the file:/// repo. I've been poking
> around the svn source code, but I'm sure its much more subtle then
> some random conditional statement. I had thought perhaps the '@' was
> getting expanded or whatnot, but that does not seem to be an issue
> either. Not all files share this behavior, despite having similar
> properties. It persists across working copy checkouts, so it doesn't
> appear to be a bad checkout. I would have to guess that somehow the
> format of the properties is affecting how SVN copies them across.
>
> Here's a snippet of the running scenario that can NOT reproduce the
> issue in a new repo:
>
> ---
> rem cleanup after our last test run
> rmdir /q /s c:\\project_files\\rename_repo
> rmdir /q /s c:\\project_files\\rename_wc
>
> cd c:\\project_files
> svnadmin create c:\\project_files\\rename_repo
> svn checkout file:///c:/project_files/rename_repo
> c:\\project_files\\rename_wc
> cd c:\\project_files\\rename_wc
> rem should have a clean repo and checkout
>
> svn ps tsvn:logtemplate "Issue number: " c:\\project_files\\rename_wc
> svn commit c:\\project_files\rename_wc -m "Adding log template"
>
> echo "The quick brown fox jumped over the brown fence." > AAAA.txt
> svn add AAAA.txt
> svn ps pebls:plcm "Test_at_1234" AAAA.txt
> svn ps pebls:sha1 "ba8cc41efc875a6dc8212ef76c579c1336597fe5" AAAA.txt
> svn ps svn:mergeinfo "/plcm/swdb:1" AAAA.txt

Um, you're not supposed to set svn:mergeinfo yourself, unless you
really, really know what you're doing. This has nothing to do with your
particular problem, it needs pointing out; this is extremely dangerous
practice.

> svn ps svn:needs-lock "x" AAAA.txt
> svn commit AAAA.txt -m "Test commit"
>
> svn pl -v AAAA.txt
> svn rename AAAA.txt BBBB.txt
> svn pl -v BBBB.txt
Received on 2015-05-01 01:58:21 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.