Re: Svn rename doesn't copy custom properties
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_renametestsvn 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_renametestsvn rename 777.txt 888.txt A 888.txt D 777.txt c:\Project_files\sandbox_v2_renametestsvn 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
Re: Svn rename doesn't copy custom properties
On 01.05.2015 17:22, Dan Ellis wrote: - 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. No, not 1.7; an SVN command-line client that is not part of TSVN. For example, http://bit.ly/1EBbkXh -- Brane
RE: Svn rename doesn't copy custom properties
Works for me. svn, version 1.8.10 (r1615264) Windows 7 C:\Users\jdoe\workspace\foobarsvn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobarsvn rename A.txt AA.txt A AA.txt D A.txt C:\Users\jdoe\workspace\foobarsvn pl -v AA.txt Properties on 'AA.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c C:\Users\jdoe\workspace\foobarsvn 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_v2svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2svn pl -v AA.txt c:\Project_files\sandbox_v2svn pl -v REN.txt
Re: Svn rename doesn't copy custom properties
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
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_v2svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2svn pl -v AA.txt c:\Project_files\sandbox_v2svn 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 danelli...@gmail.com mailto:danelli...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf d...@daniel.shahaf.name 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\sandboxsvn pl -v .txt Properties on '.txt': myprop:trace_to req12345 c:\Project_files\sandboxsvn rename .txt .txt A .txt D .txt c:\Project_files\sandboxsvn pl -v .txt c:\Project_files\sandbox
Re: Svn rename doesn't copy custom properties
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
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_v2svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2svn pl -v AA.txt c:\Project_files\sandbox_v2svn 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
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
Re: Svn rename doesn't copy custom properties
On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick jreed...@incomm.com 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
On 30.04.2015 23:52, Dan Ellis wrote: On Thu, Apr 30, 2015 at 2:30 PM, Andrew Reedick jreed...@incomm.com mailto:jreed...@incomm.com wrote: From: Dan Ellis [mailto:danelli...@gmail.com 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
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
On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf 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\sandboxsvn pl -v .txt Properties on '.txt': myprop:trace_to req12345 c:\Project_files\sandboxsvn rename .txt .txt A .txt D .txt c:\Project_files\sandboxsvn pl -v .txt c:\Project_files\sandbox
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_v2svn pl -v A.txt Properties on 'A.txt': pebls:plcm Test@4575 pebls:sha1 8cd8818d6b4f5edcb8b6e25cdf471af62bca403c c:\Project_files\sandbox_v2svn rename A.txt AA.txt A AA.txt D A.txt c:\Project_files\sandbox_v2svn pl -v AA.txt c:\Project_files\sandbox_v2svn pl -v REN.txt On Wed, Apr 29, 2015 at 4:13 PM, Dan Ellis danelli...@gmail.com wrote: On Wed, Apr 29, 2015 at 4:01 PM, Daniel Shahaf 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\sandboxsvn pl -v .txt Properties on '.txt': myprop:trace_to req12345 c:\Project_files\sandboxsvn rename .txt .txt A .txt D .txt c:\Project_files\sandboxsvn pl -v .txt c:\Project_files\sandbox
Re: Svn rename doesn't copy custom properties
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
Re: Svn rename doesn't copy custom properties
On Apr 29, 2015, at 4:13 PM, Dan Ellis danelli...@gmail.com wrote: This is specific to the rename operation (svn 1.8.9, win7): c:\Project_files\sandboxsvn pl -v .txt Properties on '.txt': myprop:trace_to req12345 c:\Project_files\sandboxsvn rename .txt .txt A .txt D .txt c:\Project_files\sandboxsvn pl -v .txt c:\Project_files\sandbox On OS X, svn 1.7.19, I see this after the rename: $ svn pl file1 Properties on 'file1': myprop $ svn rename file1 file2 A file2 D file1 $ svn status D file1 A +file2 $ svn pl file2 Properties on 'file2': myprop
