[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: Dan Ellis <danellis10_at_gmail.com>
Date: Fri, 1 May 2015 08:22:47 -0700

On Thu, Apr 30, 2015 at 8:02 PM, Daniel Shahaf <d.s_at_daniel.shahaf.name>
wrote:

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

So I added needs-lock and test:test property to a file, committed it and
did a rename. The needs-lock and new property copied, but the pebls ***
did not ***. This is really strange. Hints to something getting messed up
on the setting or recording of the property that subsequently messes up the
move operation.

c:\Project_files\sandbox_v2_renametest>svn pl -v --show-inherited-props
777.txt
Inherited properties on '777.txt',
from 'C:\Project_files\sandbox_v2_renametest':
  tsvn:logtemplate
    JIRA Issue: Description: Real Reason: Excuse:

Properties on '777.txt':
  pebls:sha1
    a8346b13d15cf519928291be808ba19c860607c1
  svn:needs-lock
    *
  test:test
    test

c:\Project_files\sandbox_v2_renametest>svn rename 777.txt 888.txt
A 888.txt
D 777.txt

c:\Project_files\sandbox_v2_renametest>svn pl -v --show-inherited-props
888.txt
Inherited properties on '888.txt',
from 'C:\Project_files\sandbox_v2_renametest':
  tsvn:logtemplate
    JIRA Issue: Description: Real Reason: Excuse:

Properties on '888.txt':
  svn:needs-lock
    *
  test:test
    test

c:\Project_files\sandbox_v2_renametest>

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

Seems to behave fine, but could be induced by your next question.

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

Yes, the pebls properties are set via a c# call to svn.exe in the form
"svn.exe ps pebls:plcm "link_at_rev" "filename", nothing stands as out of the
ordinary there, but the two calls are back to back - I did notice there are
some sleep calls in the SVN call. If it were a race condition, I would
expect a batch file to also trigger it though - unless the back to back c#
calls are not allowing the IO streams to fully flush/close?!? But how
would this cause something bad to follow a commit to the repo? I can try
putting together the scenario in a c# app to see if that might be able to
cause the issue.

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

Renaming to a path that has never existed 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]
>

Yep - have confirmed. I originally thought this was a TSVN issue, but
after reproducing at the command line, I ended up here.

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

> Moreover, does the problem persist —
>
> - if you pass --config-dir=foobar on the command-line (where 'foobar' is
> some
> empty directory)?
>

No effect.

>
> - 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?)
>

Its a local disk, not sure how to flush the disk in windows, but waiting
several minutes does not help.

>
> - if you use a different svn client?
>

Are you suggesting trying the 1.7 series? I did upgrade to svn 1.8.13
r1667537 last night which the results listed in this email are from.

>
> - if you checkout on a different computer?
>

Yes, this follows different users with different v1.8 svn clients. They
are all sourced from the v1.8 series TSVN distribution though.

>
> (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.
>
>
>
To keep from having too many replies, Brane had made a comment about not
manually using svn:mergeinfo, we don't use it, I was only mucking with it
to try and isolate the issue a bit. It stood out as one of the properties
that was set on one of the files.

I really appreciate everyone's help with this.

Dan
Received on 2015-05-01 17:23:19 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.