RE: Svn rename doesn't copy custom properties

[Andrew Reedick]

Works for me.

svn, version 1.8.10 (r1615264)
Windows 7

C:\Users\jdoe\workspace\foobar>svn pl -v A.txt
Properties on 'A.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

C:\Users\jdoe\workspace\foobar>svn rename A.txt AA.txt
A AA.txt
D A.txt

C:\Users\jdoe\workspace\foobar>svn pl -v AA.txt
Properties on 'AA.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

C:\Users\jdoe\workspace\foobar>svn st
D   A.txt
> moved to AA.txt
A  +AA.txt
> moved from A.txt

From: Dan Ellis [mailto:danelli...@gmail.com]
Sent: Wednesday, April 29, 2015 7:23 PM
To: Daniel Shahaf
Cc: Subversion Users
Subject: Re: Svn rename doesn't copy custom properties

OK, so it gets stranger...

I admit I changed the property names a bit to simplify them.  When I ran the 
simplified names, it does work.

Here's the exact example that does not work:

c:\Project_files\sandbox_v2>svn pl -v A.txt
Properties on 'A.txt':
  pebls:plcm
Test@4575
  pebls:sha1
8cd8818d6b4f5edcb8b6e25cdf471af62bca403c

c:\Project_files\sandbox_v2>svn rename A.txt AA.txt
A AA.txt
D A.txt

c:\Project_files\sandbox_v2>svn pl -v AA.txt

c:\Project_files\sandbox_v2>svn pl -v REN.txt

Re: Svn rename doesn't copy custom properties

[Branko Čibej]

On 30.04.2015 01:23, Dan Ellis wrote:
> OK, so it gets stranger...
>
> I admit I changed the property names a bit to simplify them.  When I
> ran the simplified names, it does work.
>
> Here's the exact example that does not work:
>
> c:\Project_files\sandbox_v2>svn pl -v A.txt
> Properties on 'A.txt':
>   pebls:plcm
> Test@4575
>   pebls:sha1
> 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c
>
> c:\Project_files\sandbox_v2>svn rename A.txt AA.txt
> A AA.txt
> D A.txt
>
> c:\Project_files\sandbox_v2>svn pl -v AA.txt
>
> c:\Project_files\sandbox_v2>svn pl -v REN.txt

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.

-- Brane

> On Wed, Apr 29, 2015 at 4:13 PM, Dan Ellis  > wrote:
>
>
> On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf
> mailto:d...@daniel.shahaf.name>> wrote:
>
> Dan Ellis wrote on Wed, Apr 29, 2015 at 15:43:00 -0700:
> > Hi,
> >
> > We use some custom properties for tracking (e.g.
> my_prop:trace_to
> > req_12345) and have noticed that svn renames do not copy
> these across the
> > delete/add operation.  I've tried searching the archives to
> see if I could
> > find a rationale as to why, but haven't come across any.
> >
>
> 'svn cp' and 'svn mv' do copy properties across.  How exactly
> are you
> invoking those operations?  Are you perhaps using a wrapper
> that does
> 'svn rm && svn add'?  Can you show us a transcript?
>
> On my system I see it working:
>
> [[[
> % svn pl -v baz
> Properties on 'baz':
>   k
> v
> % svn mv baz foo
> A foo
> D baz
> % svn ci -q -mm
> % svn pl -v foo
> Properties on 'foo':
>   k
> v
> ]]]
>
> > I'm guessing this could be legitimately viewed as a feature
> or a problem,
> > depending on your point of view.
> >
> > Is there a viable option to try and get svn renames to copy
> these over?
> >
>
> Including properties in mv/cp is the default behaviour and
> cannot be
> turned off (except by doing 'svn propdel' after the cp/mv and
> before
> committing).
>
> What version of the client are you using?
>
> > Thanks,
> > Dan
>
>
>
> This is specific to the rename operation (svn 1.8.9, win7):
>
> c:\Project_files\sandbox>svn pl -v .txt
> Properties on '.txt':
>   myprop:trace_to
> req12345
>
> c:\Project_files\sandbox>svn rename .txt .txt
> A .txt
> D .txt
>
> c:\Project_files\sandbox>svn pl -v .txt
>
> c:\Project_files\sandbox>
>
>

Re: Svn rename doesn't copy custom properties

[Dave Huang]

On 30.04.2015 01:23, Dan Ellis wrote:

OK, so it gets stranger...

I admit I changed the property names a bit to simplify them.  When I
ran the simplified names, it does work.


Do you perhaps have some commit hook scripts on the server that look for 
those properties and do special things with them?

Re: Svn rename doesn't copy custom properties

[Branko Čibej]

On 30.04.2015 20:04, Dave Huang wrote:
> On 30.04.2015 01:23, Dan Ellis wrote:
>> OK, so it gets stranger...
>>
>> I admit I changed the property names a bit to simplify them.  When I
>> ran the simplified names, it does work.
>
> Do you perhaps have some commit hook scripts on the server that look
> for those properties and do special things with them?

According to the posted examples, this is all client-side; no commits
were involved.

-- Brane

Re: Svn rename doesn't copy custom properties

[Dan Ellis]

>
>
>
> OK, so it gets stranger...
>
>
>
> I admit I changed the property names a bit to simplify them.  When I ran
> the simplified names, it does work.
>
>
>
> Here's the exact example that does not work:
>
>
>
> c:\Project_files\sandbox_v2>svn pl -v A.txt
>
> Properties on 'A.txt':
>
>   pebls:plcm
>
> Test@4575
>
>   pebls:sha1
>
> 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c
>
>
>
> c:\Project_files\sandbox_v2>svn rename A.txt AA.txt
>
> A AA.txt
>
> D A.txt
>
>
>
> c:\Project_files\sandbox_v2>svn pl -v AA.txt
>
>
>
> c:\Project_files\sandbox_v2>svn pl -v REN.txt
>
>
>

**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

Thanks
Dan

RE: Svn rename doesn't copy custom properties

[Andrew Reedick]

> From: Dan Ellis [mailto:danelli...@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?

Re: Svn rename doesn't copy custom properties

[Dan Ellis]

On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick  wrote:

> > From: Dan Ellis [mailto:danelli...@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." > .txt
svn add .txt
svn ps pebls:plcm "Test@1234" .txt
svn ps pebls:sha1 "ba8cc41efc875a6dc8212ef76c579c1336597fe5" .txt
svn ps svn:mergeinfo "/plcm/swdb:1" .txt
svn ps svn:needs-lock "x" .txt
svn commit .txt -m "Test commit"

svn pl -v .txt
svn rename .txt .txt
svn pl -v .txt

Re: Svn rename doesn't copy custom properties

[Branko Čibej]

On 30.04.2015 23:52, Dan Ellis wrote:
>
>
> On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick  > wrote:
>
> > From: Dan Ellis [mailto:danelli...@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." > .txt
> svn add .txt
> svn ps pebls:plcm "Test@1234" .txt
> svn ps pebls:sha1 "ba8cc41efc875a6dc8212ef76c579c1336597fe5" .txt
> svn ps svn:mergeinfo "/plcm/swdb:1" .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" .txt
> svn commit .txt -m "Test commit"
>
> svn pl -v .txt
> svn rename .txt .txt
> svn pl -v .txt

Re: Svn rename doesn't copy custom properties

[Daniel Shahaf]

Dan Ellis wrote on Thu, Apr 30, 2015 at 14:52:23 -0700:
> Here's a snippet of the running scenario that can NOT reproduce the issue
> in a new repo:

In the situation that reproduces the problem:

- What happens when renaming a file that has both pebls:* properties and other
  properties?

- What happens when renaming a file that has some properties but no pebls:*
  properties?

- Do you have any automated handling of pebls:* properties anywhere in svn or
  tortoisesvn?  (e.g., client-side hooks, auto-props, …)

- Is the target of a rename a path that never existed either in the repository
  or in that working copy, at any revision?

- Could you confirm via the TortoiseSVN GUI that the pebls:* really are unset
  after the rename?  [To rule out output buffering issues]

- Does 'svn' invoke svn.exe directly, or does it invoke a wrapper script?

Moreover, does the problem persist —

- if you pass --config-dir=foobar on the command-line (where 'foobar' is some
  empty directory)?

- if you flush the disk caches between the rename and the final proplist?  (Is
  the working copy on a network drive or on local disk?)

- if you use a different svn client?

- if you checkout on a different computer?

(to devs) Is there an sqlite pragma that logs every statement executed
on the database (by any process)?  I'd love to turn that on just to
confirm that we don't have a process deleting the props as soon as the
'svn' process finished doing the rename.

I realize I'm shooting in all directions, but hopefully this narrows it
down a bit.

Cheers,

Daniel

> 
> ---
> 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." > .txt
> svn add .txt
> svn ps pebls:plcm "Test@1234" .txt
> svn ps pebls:sha1 "ba8cc41efc875a6dc8212ef76c579c1336597fe5" .txt
> svn ps svn:mergeinfo "/plcm/swdb:1" .txt
> svn ps svn:needs-lock "x" .txt
> svn commit .txt -m "Test commit"
> 
> svn pl -v .txt
> svn rename .txt .txt
> svn pl -v .txt