On Thu, Apr 30, 2015 at 8:02 PM, Daniel Shahaf <d...@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@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
