svnmucc --revision 0 no longer works when creating a file
When I first started using svnmucc, it used to be the case that svnmucc 'put' --revision 0 would fail if the target file already existed. This no longer happens. The previous behaviour was very useful, so are there any plans to reinstate it? I don't think there is a straightforward way to guarantee the same behaviour now. The closest I could get is: 1) get current parent directory revision 2) check if target file does not exist. This is not as easy as it sounds, as the target directory may have too many files to list efficiently, and any other file-based command may fail for a reason other than a missing file. 3) Put the file using the revision obtained in step 1. AFAICT this is guaranteed not to replace an existing file. However it may fail to create the file if the target directory has been updated in the meantime. It's only safe to repeat the attempted create if the command failed due to an out of date revision. So the failure reason will have to be analysed.
Re: Restriction on svnmucc targets in same repository?
sebb wrote on Tue, 07 Jul 2020 12:55 +0100: > Is there any restriction on svnmucc targets which can appear in a batch > script? > > I assume that all targets must be in the same repository, but are > there any further restrictions, e.g. must they have the same initial > root directory path? > > I ask this because I am getting the following: > > svnmucc: E175013: Access to '/.../!svn/rvr/98024' forbidden > > The script is equivalent to: > > put > file.txt > top1/file.txt > > mv > top2/d1/file2.txt > top2/d2/file2.txt > > top1 and top2 are different top-level root folders in the same repository, > i.e. > svn info root/top1 gives the same UUID as svn info root/top2 There are no restrictions other than "in the same repository". However, if you edit both ^/top1/foo and ^/top2/bar in the same revision, the edit drive will be rooted on ^/, and it's possible you need 'w' access on ^/ in the authz file for that to work. (See «svnauthz accessof») And of course, check the server logs for hints.
Restriction on svnmucc targets in same repository?
Is there any restriction on svnmucc targets which can appear in a batch script? I assume that all targets must be in the same repository, but are there any further restrictions, e.g. must they have the same initial root directory path? I ask this because I am getting the following: svnmucc: E175013: Access to '/.../!svn/rvr/98024' forbidden The script is equivalent to: put file.txt top1/file.txt mv top2/d1/file2.txt top2/d2/file2.txt top1 and top2 are different top-level root folders in the same repository, i.e. svn info root/top1 gives the same UUID as svn info root/top2 Sebb
Sv: invalid status for updating properties
Hi Yeah, I linked to that issue in my first mail since I thought it could be related also, but reading that ticket I thought it didn't exactly match my issue. I guess I'll have to retry once that fix gets released. Regards, Mikael Från: Stefan Sperling Skickat: den 7 juli 2020 11:12 Till: Mikael Stålhammar Kopia: users@subversion.apache.org Ämne: Re: invalid status for updating properties On Tue, Jul 07, 2020 at 09:01:50AM +, Mikael Stålhammar wrote: > Hi > I'm having an issue with merging/releasing a feature branch to trunk, getting: > > > --- Recording mergeinfo for merge between repository URLs into '.': > > svn: E155023: Can't set properties on > 'E:\SVN\WorkingCopies\repo\trunk\folder\file.txt': invalid status for > updating properties. This looks like the problem tracked in this issue: https://issues.apache.org/jira/browse/SVN-4859 A fix is being worked on and has already been committed to trunk. See https://svn.apache.org/r1879192
Re: invalid status for updating properties
On Tue, Jul 07, 2020 at 09:01:50AM +, Mikael Stålhammar wrote: > Hi > I'm having an issue with merging/releasing a feature branch to trunk, getting: > > > --- Recording mergeinfo for merge between repository URLs into '.': > > svn: E155023: Can't set properties on > 'E:\SVN\WorkingCopies\repo\trunk\folder\file.txt': invalid status for > updating properties. This looks like the problem tracked in this issue: https://issues.apache.org/jira/browse/SVN-4859 A fix is being worked on and has already been committed to trunk. See https://svn.apache.org/r1879192
invalid status for updating properties
Hi I'm having an issue with merging/releasing a feature branch to trunk, getting: --- Recording mergeinfo for merge between repository URLs into '.': svn: E155023: Can't set properties on 'E:\SVN\WorkingCopies\repo\trunk\folder\file.txt': invalid status for updating properties. The background is this: -The "file.txt" was created on trunk a while back and has been merged into the feature branches. -We are working on trunk and feature branches using sparse checkouts, having only the files we need in the working copies, committing files individually. Files changed on trunk are then merged in, file-by-file i.e. using subtree merging on file level, to a branch when needed. I.e. the merge info property is set on the merged files. The "file.txt" was recently deleted on a branch and the deletion has been committed. Now the work on that branch is ready and it's about to be merged back into trunk. The branch release process: 1. The branch is fully checked out in a working copy. Trunk is successfully merged into that working copy and committed. 2. Trunk is fully checked out in a working copy. The branch is merged into that working copy but then the error above occurs, saying it can't set properties on the deleted file. Why does SVN even try to set properties on a deleted file? In the log from the merge, before the error message mentioned above, everything looks fine, i.e. a bunch of lines for "Updated" files and one "Deleted" file (the "file.txt"). I searched among the bugs but the only one I could find somewhat releated was this quite recent one: https://issues.apache.org/jira/browse/SVN-4859 But while the error message was related I don't think it's the issue I have. So I'm wondering what could be the issue, something we've done wrong or a bug? Is the problem in the SVN client or server? (I used Tortoise/SVN 1.14.0 as client when merging. I think it's SVN 1.8.5 on the server) Regards, Mikael
