SVN lock at version 1.8.3 and 1.8.4 - not working
We use Apache Subversion1.8.3 and i now tested new Apache Subversion 1.8.4 and got same result. When i checked out repo and tried to get lock on file, i got result bellow: C:\software\test\test6>c:\software\Subversion\bin\svn.exe lock --username iras24 test001/testfile.txt svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL svn: E200035: Additional errors: svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL from error.log (apache had debug level set): [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization result of : denied (no authenticated user yet) [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization result of Require valid-user : granted [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization result of : granted [Fri Nov 15 16:05:16.421641 2013] [dav:error] [pid 9844:tid 1032] [client 127.0.0.1:53766] Tried to attach multiple locks to a resource. [400, #405] Server: Windows 2012 server 64bit, Apache 2.4 32bit, Subversion 1.8.3 32bit Testing PC: Windows 7, Apache 2.4, Subversion 1.8.4, all 32bit For both versions was used client with equivalent version connecting to http://localhost... Steps: - checkout - get lock - got error No update was did, so known bug at tigris bellow may be or not may be related. For both versions are same errors at client side, same error log records at the servers. Please, any have same problem? Anybody knows solutions? Please, help me to solve it. Perhaps some one or more infos bellow are related: https://bitbucket.org/sdorra/scm-manager/issue/420/svn-locks-does-not-work-with-svnkit http://subversion.tigris.org/issues/show_bug.cgi?id=4412 Thanks Vena Kovar
RE: SVN lock at version 1.8.3 and 1.8.4 - not working
> -Original Message- > From: Kovar, Vaclav (EOM) [mailto:vaclav.ko...@skoda-auto.cz] > Sent: vrijdag 15 november 2013 16:42 > To: users@subversion.apache.org > Subject: SVN lock at version 1.8.3 and 1.8.4 - not working > > We use Apache Subversion1.8.3 and i now tested new Apache Subversion > 1.8.4 and got same result. When i checked out repo and tried to get lock on > file, i got result bellow: > > C:\software\test\test6>c:\software\Subversion\bin\svn.exe lock -- > username iras24 test001/testfile.txt > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL > svn: E200035: Additional errors: > svn: E200035: sqlite[S19]: LOCK.lock_token may not be NULL > > from error.log (apache had debug level set): > > [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] > mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization > result of : denied (no authenticated user yet) > [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] > mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization > result of Require valid-user : granted > [Fri Nov 15 16:05:16.421641 2013] [authz_core:debug] [pid 9844:tid 1032] > mod_authz_core.c(799): [client 127.0.0.1:53766] AH01626: authorization > result of : granted > [Fri Nov 15 16:05:16.421641 2013] [dav:error] [pid 9844:tid 1032] [client > 127.0.0.1:53766] Tried to attach multiple locks to a resource. [400, #405] What output does your 'pre-lock' hook template produce? My guess would be that it produces something... >From the standard template you get on 'svnadmin create': #!/bin/sh # PRE-LOCK HOOK # # The pre-lock hook is invoked before an exclusive lock is # created. Subversion runs this hook by invoking a program # (script, executable, binary, etc.) named 'pre-lock' (for which # this file is a template), with the following ordered arguments: # # [1] REPOS-PATH (the path to this repository) # [2] PATH (the path in the repository about to be locked) # [3] USER (the user creating the lock) # [4] COMMENT (the comment of the lock) # [5] STEAL-LOCK (1 if the user is trying to steal the lock, else 0) # # If the hook program outputs anything on stdout, the output string will # be used as the lock token for this lock operation. If you choose to use # this feature, you must guarantee the tokens generated are unique across # the repository each time. Bert
Extended Attributes in MacOS X?
I have an ECAD package which writes its project filename (think of a Makefile) without a Unixish dot extension. When this file is checked out from SVN its tagged as a text file of some sort and can not be opened by dragging it to the application, from within the application, or right click Open With... or nothing. Its terribly important because this project file is the front door for working on other files in the project. What I've done is add a fixit.sh to the folder (where the project file is "Test"): #!/bin/sh xattr -wx com.apple.FinderInfo "50 52 4A 34 4D 43 53 58 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00" Test The above sets the traditional Mac CREATOR and TYPE attributes to PRJ4 and MCSX. Schematic files have dot extensions to their names and Finder figures out on its own how to repair their extended attributes. Searching archives and the internet I know there has been a lot of discussion about supporting extended attributes but I can't find where anything has been done about it. What I've done is create a caveman-simple client side hook, one that has to be manually executed. Would be nice to be able to automate this without having alias or redirect /usr/bin/svn through a shell second guessing what svn is being asked to do. Would be nice to be able to add an SVN property, perhaps darwin:com.apple.FinderInfo that reads the current value from the file on commit and sets that as the SVN property value, and on update/checkout writes the value to the working file. How do others handle this issue? -- David Kelly N4HHE, dke...@hiwaay.net Whom computers would destroy, they must first drive mad.
Re: svn delete removes read-only files
Branko Čibej wandisco.com> writes: > I disagree with the behaviour change because it makes 'svn delete' in > the presence of svn:needs-lock behave exactly opposite to every other > command. IMO, it's quite enough to simply fix the bug where we try to > change the permissions on a non-existent local path. > > So I suggest you file a bug for that, not for the behaviour change. In general I understand the point about behavior consistency, and I agree this is important. By behave opposite you mean that if 'svn delete' changes its behavior in the presence of svn:needs-lock, this would be opposite of other commands that ignore whether it is present? My suggestion is not to look for the presence of svn:needs-lock, but to honor file permissions when doing 'svn delete', irrespective of whether svn:needs-lock is set. I think there would be symmetry between this behavior and how svn currently handles file permissions: svn makes files with svn:needs-lock present read-only if no lock is set, so users that try to edit the file notice it is read-only, and take appropriate action - get the lock. In the same way, if 'svn delete' warned about or refused to delete read-only files, the user would be reminded to get the lock. This behavior is similar to how the unix rm command behaves. I think this would be more intuitive. > > > We won't fix this in 1.6 and 1.8 is already fixed: > > $ svn rm wc/A/f > D wc/A/f > $ svn st wc/A/f > D wc/A/f > $ svn lock wc/A/f > 'f' locked by user 'pm'. > $ svn st wc/A/f > DK wc/A/f > > > > Yes, I was just going to say. I added test cases for this on > trunk, and they passed; I've just been running them on 1.8, where > they pass as well. > In other words, upgrading to 1.8 will fix the issue, and in the > meantime, ask your users to either revert the delete first (i.e., > 'svn revert file; svn lock file; svn rm file; svn commit', or to > use the URL in the 'svn lock' command. > > > And here's the related issue:http://subversion.tigris.org/issues/show_bug.cgi?id=4304 Good - I agree the error message on lock/unlock is a bug, and it is good to know that it is now fixed. Best regards, Rick
Re: svn delete removes read-only files
On 15.11.2013 20:30, Rick Varney wrote: > Branko Čibej wandisco.com> writes: > >> I disagree with the behaviour change because it makes 'svn > delete' in >> the presence of svn:needs-lock behave exactly opposite to every other >> command. IMO, it's quite enough to simply fix the bug where we try to >> change the permissions on a non-existent local path. >> >> So I suggest you file a bug for that, not for the behaviour change. > In general I understand the point about behavior consistency, and I agree > this is important. > > By behave opposite you mean that if 'svn delete' changes its behavior in the > presence of svn:needs-lock, this would be opposite of other commands that > ignore whether it is present? > > My suggestion is not to look for the presence of svn:needs-lock, but to > honor file permissions when doing 'svn delete', irrespective of whether > svn:needs-lock is set. You're allowed to modify and commit changes to a file that has the svn:needs-lock property regardless of whether it's locked or not. svn:needs-lock is not a constraint, it's just a reminder. "svn delete" is not, and should not be, special. FWIW, I've seen editors that automagically make a file writable if you start modifying it ... > I think there would be symmetry between this behavior and how svn currently > handles file permissions: svn makes files with svn:needs-lock present > read-only if no lock is set, so users that try to edit the file notice it is > read-only, and take appropriate action - get the lock. > > In the same way, if 'svn delete' warned about or refused to delete read-only > files, the user would be reminded to get the lock. This behavior is similar > to how the unix rm command behaves. It really depends on what you think "Unix rm" actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. Given that you can lock a deleted file, I really don't see a problem. If Subversion started prompting the user in such cases, the change in behaviour might break scripts for people who depend on the Unix-like delete behaviour, where file permissions don't matter but directory permissions do. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
RE: Migrating ClearCase data to Subversion
Did you try this tool. It is what I used to migrate from PVCS. http://www.polarion.com/products/svn/svn_importer.php BOb From: Olivier Antoine [mailto:oliviera201...@gmail.com] Sent: Friday, November 15, 2013 5:47 PM To: users@subversion.apache.org Subject: Migrating ClearCase data to Subversion Hi, I could not find a tool or an automated way to migrate ClearCase vobs to SVN repositories. I guess there is not any perfect tool to do this. I don't think I can use timestamp to build revisions, like for migration cvs to svn. On the other hand, the real need is to migrate main to trunk, to migrate the other branches, probably just for the interesting file/directory versions - the labelelled ones. I have to migrate the ClearCase labels to SVN tags. I guess it is not possible to migrate the merge history. Could you help, please ? Olivier
Migrating ClearCase data to Subversion
Hi, I could not find a tool or an automated way to migrate ClearCase vobs to SVN repositories. I guess there is not any perfect tool to do this. I don't think I can use timestamp to build revisions, like for migration cvs to svn. On the other hand, the real need is to migrate main to trunk, to migrate the other branches, probably just for the interesting file/directory versions - the labelelled ones. I have to migrate the ClearCase labels to SVN tags. I guess it is not possible to migrate the merge history. Could you help, please ? Olivier
Re: svn delete removes read-only files
Branko Čibej wandisco.com> writes: > > > On 15.11.2013 20:30, Rick Varney wrote: > > > Branko Čibej wandisco.com> writes: > > > > I disagree with the behaviour change because it makes 'svn > > > delete' in > > > the presence of svn:needs-lock behave exactly opposite to every other > command. IMO, it's quite enough to simply fix the bug where we try to > change the permissions on a non-existent local path. > > So I suggest you file a bug for that, not for the behaviour change. > > > > In general I understand the point about behavior consistency, and I agree > this is important. > > By behave opposite you mean that if 'svn delete' changes its behavior in the > presence of svn:needs-lock, this would be opposite of other commands that > ignore whether it is present? > > My suggestion is not to look for the presence of svn:needs-lock, but to > honor file permissions when doing 'svn delete', irrespective of whether > svn:needs-lock is set. > > > You're allowed to modify and commit changes to a file that has the > svn:needs-lock property regardless of whether it's locked or not. > svn:needs-lock is not a constraint, it's just a reminder. I see. I was thinking of it as a constraint, because we had customized our setup to prevent checking in unlocked files in our pre-commit hook script. Unfortunately, this same method can't be used to customize the svn delete behavior, because the local file deletion happens exclusively on the client side. Only at commit time will the user be reminded there is an issue. > "svn > delete" is not, and should not be, special. FWIW, I've seen editors > that automagically make a file writable if you start modifying it > ... > I think there would be symmetry between this behavior and how svn currently > handles file permissions: svn makes files with svn:needs-lock present > read-only if no lock is set, so users that try to edit the file notice it is > read-only, and take appropriate action - get the lock. > > In the same way, if 'svn delete' warned about or refused to delete read-only > files, the user would be reminded to get the lock. This behavior is similar > to how the unix rm command behaves. > > > It really depends on what you think "Unix rm" actually is. The > unlink() or remove() functions don't care about permissions on the > target, only that you have write permission on the parent directory. It does not surprise me to hear that system functions don't care about file permissions. The OS flavor I'm most familiar with is rhel5. Here is how the interactive rm command behaves in this case: $ ll foo.txt -r--r- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt $ rm foo.txt rm: remove write-protected regular file `foo.txt'? y So while rm is perfectly capable of removing the read-only file in a directory where I have write permissions, it politely asks first. I had assumed the rm command behaves similarly on many flavors of Unix (as well as Linux). > Given that you can lock a deleted file, I really don't see a > problem. If Subversion started prompting the user in such cases, the > change in behaviour might break scripts for people who depend on the > Unix-like delete behaviour, where file permissions don't matter but > directory permissions do. Your last point is hard to refute - it would be change in behavior, and would mess up existing scripting that does not expect interactive prompts. Maybe this behavior can be made optional, enabled via the configuration file? Locking a deleted file will work in the end. It is just a little less intuitive, in my my opinion. Best regards, Rick
Re: svn delete removes read-only files
On 11/15/2013 3:57 PM, Rick Varney wrote: Branko Čibej wandisco.com> writes: It really depends on what you think "Unix rm" actually is. The unlink() or remove() functions don't care about permissions on the target, only that you have write permission on the parent directory. It does not surprise me to hear that system functions don't care about file permissions. The OS flavor I'm most familiar with is rhel5. Here is how the interactive rm command behaves in this case: $ ll foo.txt -r--r- 1 usb00219 nxp 4 Nov 15 15:42 foo.txt $ rm foo.txt rm: remove write-protected regular file `foo.txt'? y So while rm is perfectly capable of removing the read-only file in a directory where I have write permissions, it politely asks first. I had assumed the rm command behaves similarly on many flavors of Unix (as well as Linux). This is probably due to an alias set up in your login script, e.g. .bashrc. Type "alias" at the command prompt; you will probably find that "rm" is aliased to "rm -i", which prompts before removing files. "rm" does not prompt like this by default. "ll" is not a Unix/Linux command either, so it's a pretty safe bet that you have aliases set up, either in the distro you have installed, or configured by your sysadmin (on my CentOS machines, this alias is present only for the root account by default). Try "\rm foo.txt" (backslash before executable name); I'll bet that it does not ask you for permission to remove a write-protected file. -- David Chapman dcchap...@acm.org Chapman Consulting -- San Jose, CA Software Development Done Right. www.chapman-consulting-sj.com
Re: svn delete removes read-only files
On 16.11.2013 00:57, Rick Varney wrote: > Branko Čibej wandisco.com> writes: > >> >> You're allowed to modify and commit changes to a file that has the >> svn:needs-lock property regardless of whether it's locked or not. >> svn:needs-lock is not a constraint, it's just a reminder. > I see. I was thinking of it as a constraint, because we had customized our > setup to prevent checking in unlocked files in our pre-commit hook script. Sure, you can use a pre-commit hook to prevent committing files without locks; but there's nothing you can do to prevent anyone from editing it, short of using advanced access control in the working copy directories and modifying or otherwise wrapping the Subversion command-line client. > Maybe this behavior can be made optional, enabled via the > configuration file? Changing client behaviour via config file options is almost always a bad idea ... every such option makes testing more complex and bug triage more time consuming. I'm not saying that there's no chance we'd ever change the way 'svn delete' behaves; I only stated some of the arguments against that, and there can certainly be other opinions. But we'd have to see some indication that the case you describe is actually moderately common. Frankly, I doubt it is; because mandatory locking isn't, in my experience, a very common workflow with Subversion. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
svnmucc
Hi, My svnmucc 1.8.4 can't work with commands from a file, like these (saved as 'normalize.mucc'): rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags I try execute them via svnmucc: svnmucc -U file:///X:/SVN/Kolibri.com -X normalize.mucc -m "Normalization" It causes me an error: svnmucc: E24: 'rm programs/develop/fasm/tags' is not an action I looked into the sources and found this error like svnmucc treats the entire string 'rm programs/develop/fasm/tags' as single command. Is it real? Is it common issue, not just for Windows? -- WBR, Vladislav Javadov
