Can not do autoimic commit for deleted forlder and modification in some other folders/ files.
Hello, I am using SVN command line client 1.6.2 on windows. I have following folder structure Trunk Folder1 File1 File2 Folder2 File3 File4 Folder3 File5 File6 I have perform following local operations changed Folder1's property. Modified File1 Deleted Folder2 I would like to do the commit of following Property change in Folder1 Deleted Folder2 But don't want to commit the changes done in File1. How can I do it with one svn commit command ( atomic commit ). If we use Svn commit --m msg Trunk\Folder1 Trunk\Folder2 It will work properly but will also commit the changes in Trunk\Folder1\File1 To avoid it if we use Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2\File3 Trunk\Folder2\File4 Trunk\Folder2 Commit fails as it does not get the File3, file4 on disk. Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2 Commit fails as with error. svn: Cannot non-recursively commit a directory deletion of a directory with child nodes Is this a bug or is there any way to perform atomic commit in the scenario explained. Thanks and regards, Sachin.
Re: Can not do autoimic commit for deleted forlder and modification in some other folders/ files.
On Nov 24, 2011, at 01:47, Sachin Deshpande wrote: I have perform following local operations changed Folder1’s property. Modified File1 Deleted Folder2 I would like to do the commit of following Property change in Folder1 Deleted Folder2 But don’t want to commit the changes done in File1. How can I do it with one svn commit command ( atomic commit ). Save the modifications for File1 in a diff, or save a copy of File1 Revert the changes to File1 Commit Folder1 and Folder2 Apply the diff you saved to File1 (or restore the modified File1 from the copy you made) Another possibility might be to use svnmucc to to the property change and the directory deletion.
Re: Can not do autoimic commit for deleted forlder and modification in some other folders/ files.
On 24/11/11 07:47, Sachin Deshpande wrote: Hello, I am using SVN command line client 1.6.2 on windows. I have following folder structure Trunk Folder1 File1 File2 Folder2 File3 File4 Folder3 File5 File6 I have perform following local operations changed *Folder1*'s property. Modified *File1* Deleted *Folder2* ** I would like to do the commit of following Property change in Folder1 Deleted Folder2 *But don't want to commit the changes done in File1.* How can I do it with one svn commit command ( atomic commit ). If we use Svn commit --m msg Trunk\Folder1 Trunk\Folder2 It will work properly but will also commit the changes in Trunk\Folder1\File1 To avoid it if we use Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2\File3 Trunk\Folder2\File4 Trunk\Folder2 Commit fails as it does not get the File3, file4 on disk. Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2 Commit fails as with error. svn: Cannot non-recursively commit a directory deletion of a directory with child nodes Is this a bug or is there any way to perform atomic commit in the scenario explained. Thanks and regards, Sachin. I haven't tested this but my first idea would be to use changelists. Add Folder1 and Folder2 to a changelist svn cl test Trunk\Folder1 svn cl test Trunk\Folder2 and then remove File1 from it svn cl test --remove Trunk\Folder1\File1 Check that the changelist contains exactly what you want svn st Finally, commit using the changelist svn ci --changelist test -m msg As I said, I haven't tested this. Good luck Giulio
RE: Can not do autoimic commit for deleted forlder and modification in some other folders/ files.
Hello Giulio, Thank you very much for your prompt reply. I have found a document on net that says changelists work with files and not with Folders. Also tested it, svn cl skips folders. The output message is Skipped 'foldername' Thanks and regards, Sachin. From: Giulio Troccoli [mailto:giulio.trocc...@mediatelgroup.co.uk] Sent: Thursday, November 24, 2011 2:38 PM To: Sachin Deshpande Cc: users@subversion.apache.org; 'Christophe Meyer'; 'Sandeep Gupta'; 'Hans'; 'Thierry Vouriot' Subject: Re: Can not do autoimic commit for deleted forlder and modification in some other folders/ files. On 24/11/11 07:47, Sachin Deshpande wrote: Hello, I am using SVN command line client 1.6.2 on windows. I have following folder structure Trunk Folder1 File1 File2 Folder2 File3 File4 Folder3 File5 File6 I have perform following local operations changed Folder1's property. Modified File1 Deleted Folder2 I would like to do the commit of following Property change in Folder1 Deleted Folder2 But don't want to commit the changes done in File1. How can I do it with one svn commit command ( atomic commit ). If we use Svn commit --m msg Trunk\Folder1 Trunk\Folder2 It will work properly but will also commit the changes in Trunk\Folder1\File1 To avoid it if we use Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2\File3 Trunk\Folder2\File4 Trunk\Folder2 Commit fails as it does not get the File3, file4 on disk. Svn commit --m msg --depth=empty Trunk\Folder1 Trunk\Folder2 Commit fails as with error. svn: Cannot non-recursively commit a directory deletion of a directory with child nodes Is this a bug or is there any way to perform atomic commit in the scenario explained. Thanks and regards, Sachin. I haven't tested this but my first idea would be to use changelists. Add Folder1 and Folder2 to a changelist svn cl test Trunk\Folder1 svn cl test Trunk\Folder2 and then remove File1 from it svn cl test --remove Trunk\Folder1\File1 Check that the changelist contains exactly what you want svn st Finally, commit using the changelist svn ci --changelist test -m msg As I said, I haven't tested this. Good luck Giulio
Apache and subversion per directory authorizations with different group source.
Dear people, I have setup Apache 2.2 and subversion. I'm using an Apache module for authentication and authzsvnaccess to define groups an manage per directory authorizations for them. But this requires me to define the groups and memberships in the authzsvnaccess file. I already have setup a different authorization source in Apache for other sites/directories (mod-auth-mysql). Is it possible to use the authzsvnaccess file for defining which users and groups have what access to which directory, but refer to the group names as defined in the other authorization module? Right now I need to manage group memberships both in a database and in the authzsvnaccess file, while I need to maintain the usernames and password only in the database. Cheers, Dolf andringa.
Re: Apache and subversion per directory authorizations with different group source.
2011/11/24 Dolf Andringa dandri...@proigia.nl Dear people, I have setup Apache 2.2 and subversion. I'm using an Apache module for authentication and authzsvnaccess to define groups an manage per directory authorizations for them. But this requires me to define the groups and memberships in the authzsvnaccess file. I already have setup a different authorization source in Apache for other sites/directories (mod-auth-mysql). Is it possible to use the authzsvnaccess file for defining which users and groups have what access to which directory, but refer to the group names as defined in the other authorization module? Right now I need to manage group memberships both in a database and in the authzsvnaccess file, while I need to maintain the usernames and password only in the database.He only solution today is to write a piece of code that exports the groups As far as I know the only solution available today is to write a tiny application that exports the groups from the mysql database and builds an authz file based on that. If you know a little coding (in any language that can connect to mysql) that shouldn't be very difficult. The groups a user belongs to are not passed to the authz module. All it knows is the username.
Re: [ANN] SubGit Early Access Program Build #789
On Tue, Nov 22, 2011 at 10:17 AM, Alexander Kitaev kit...@tmatesoft.com wrote: Hello All, Let me introduce our new project: SubGit (http://subgit.com/). SubGit is a free tool for smooth migration from Subversion to Git. As well as from Git to Subversion. Without git-svn insanity. It works like this: You've just hurt my brain even thinking about this. The migration of svn:keywords, svn:eol, from git back to Subversion on a live sytem make my brain hurt eventhinking about it. And the potential for mutiple Subversion repository split-brain problems with git style development, tied to multiple upstream subversion repositories, is tying my brain in a knot. If I can pry a few cycles free, I'll take a glance at it. But the idea of running parallel subversion and git access to the same upstream repository makes me very nervous. - Install SubGit into your repository on the server side - Let initial translation complete (time depends on the size of repository) - Committers may now use either Git or Subversion (or both) with the tools of their choice SubGit EAP builds are free to use builds which you may try and let us know what do you miss, so that we make sure that all the features you need are included into the final version of SubGit. SubGit works on Linux, Windows or OS X and requires Java 5 or newer.Download new SubGit EAP build from http://subgit.com/ Alexander Kitaev, TMate Software, http://subgit.com/ - Two-way ticket to the dark side. http://svnkit.com/ - Java [Sub]Versioning Library! http://hg4j.com/ - Java Mercurial Library! http://sqljet.com/ - Java SQLite Library!
Re: workqueue.c line 672: assertion failed (checksum !=NULL)
No, he meant your working copy is corrupted and you need to check out another. The working copy upgrade process cannot handle certain types of working copy corruption. I tried it, I checked out my project again (several gigabytes!) and I encountered problems again. A colleague did the same migration but his project doesn't have externals while mine has tons of 'em. I think there may be an issue with the updating of directories from 1.6.x to 1.7.1 especially in the handling of the externals references. Anyway I went back to 1.6.x and everything's fine for me. -- View this message in context: http://old.nabble.com/workqueue.c-line-672%3A-assertion-failed-%28checksum-%21%3DNULL%29-tp32690129p32875469.html Sent from the Subversion Users mailing list archive at Nabble.com.
Re: Bug: Subversion Windows installer not setting paths correctly
Hi again Bert. Today I've tested this on a (almost) clean Win7 installation I had without problems. I did first a clean install to C:\Test\Subversion... APR_ICONV_PATH was set correctly. I also did a install of first 1.6.17 to C:\Program Files\Subversion and then an upgrade to 1.7.1 to C:\Test\Subversion and the only traces of the 1.6.17 install was some licence files and in the PATH environment variable.APR_ICONV_PATH was correct this time too. I noted that APR_ICONV_PATH is set as User environment variable, maybe you did previous installs for another user and that users variable had the value from this install ? I don't know why it's set just for current user. I didn't create the install scripts, just using them and making necessary modifications. Maybe I should change this for upcoming releases. It could also be that you used the very old exe-installer from Tigris. This one (from what I found in the source code in the repository) did set APR_ICONV_PATH for both current user and for system. You can check the environment variables in the registry by running regedit as administrator. For the users the path is HKEY_USERS\userid\Environement and for all users HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment|| /David ps. Please use Reply to all so subsequent mail is also sent to the list for others to follow and search for solutions. On 2011-11-23 23:36, Humberto Madeira wrote: Hi David, I actually had 2 installs, one was 1.7.0 and the other was 1.7.1 Both previously had Subversion 1.6.x and Python 2.5.x on them, installed on the default path. I had recently decided that since I put all my Apache products under c:\Apache now that Subversion also qualifies as Apache, I should move it under the Apache tree, so to speak. I made both changes on the 1.7.0 box a couple of weeks ago, (updating from 1.6.x) ran into this problem, didn't write it down (too busy) and left that one working. Then I made the change on the new 1.7.1 this week and ran into the same problems (thinking I had set the path properly) So I ran into the same wild goose chase again until I decided to compare the fully working one to the partly working one. On older versions I just accepted the default path. Regards, --Bert *s...@alagazam.net* 23/11/2011 05:05 PM To Humberto Madeira humberto.made...@trapezegroup.com cc users@subversion.apache.org Subject Re: Bug: Subversion Windows installer not setting paths correctly On 2011-11-23 21:44, Humberto Madeira wrote: Hi all, I ran across a bug with the Windows (msi) Subversion installer where it was not setting the paths correctly during an install with a non-default path. To Reproduce: 1) download Setup-Subversion-1.7.1.msi from _http://sourceforge.net/projects/win32svn/files/1.7.1/Setup-Subversion-1.7.1.msi/download_ 2) use it to install Subversion into c:\Apache\Subversion instead of the default c:\Program Files\Subversion You will find the files in the correct place, but the APR_ICONV_PATH and the PATH will still point to c:\Program Files\Subversion Your operating system Windows Server 2003 Standard Edition (32 bit) Service Pack 2 The release and/or revision of Subversion 1.7.1 The compiler and configuration options you built Subversion with binary built and packaged by David Darj and up on SourceForge (see above) Any private modifications you made to your Subversion nope The version of Berkeley DB you're running Subversion with, if any nope - using FSFS Anything else that could possibly be relevant. Err on the side of too much information, rather than too little. Using it with Apache httpd-2.2.21-win32-x86-openssl-0.9.8r.msi (not using the SSL) Using it with Python2.7.2 from Python.org Using the python bindings svn-win32-1.7.1_py27.zip from David Darj (as per above) Note: this path problem is not easy to spot (if you didn't expect it) so I first caught it when trying to commit. Since I use case-insensitive.py in the pre-commit hook - the problem gets reported in the Python stack trace - which then leads you onto a wild goose chase in the Python path setup (which is actually fine but since you aren't able to tell, distracts you from the real problem) Best Regards all --Bert Hi Bert. Thanks for the bug report. I'll try to look into this problem in the next few days. My first look at the installer build file it seems to be set correctly as [INSTALLDIR]iconv and a quick test on my old Win2000Server did set the correct path (but the notes on the installer end page was wrong). Is this a fresh install of Subversion or did you upgrade from a previous version, maybe installed on the default path? Have you experiences this problem on previous versions of my installers ? Regards /David
Re: workqueue.c line 672: assertion failed (checksum !=NULL)
On Thu, Nov 24, 2011 at 6:27 PM, AlfredD michel.chare...@teledynedalsa.com wrote: No, he meant your working copy is corrupted and you need to check out another. The working copy upgrade process cannot handle certain types of working copy corruption. I tried it, I checked out my project again (several gigabytes!) and I encountered problems again. A colleague did the same migration but his project doesn't have externals while mine has tons of 'em. I think there may be an issue with the updating of directories from 1.6.x to 1.7.1 especially in the handling of the externals references. But as you said, you also encountered this problem with a new checkout (checkout done with 1.7.1 of course). So how can this be upgrade-related? -- Johan
Re: Bug: Subversion Windows installer not setting paths correctly
Hi David, For the users the path is HKEY_USERS\userid\Environement Yes, or simply HKEY_CURRENT_USER\Environment However, this install was meant to be used as a server for multiple users. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment just contains all of the data from the System/Environment panel. I noted that APR_ICONV_PATH is set as User environment variable, maybe you did previous installs for another user and that users variable had the value from this install ? Oops, sorry. Good point - I always manually change this value to a system environment variable (this is a server after all) I don't know why it's set just for current user. I didn't create the install scripts, just using them and making necessary modifications. Maybe I should change this for upcoming releases. I always assumed it was optimized for someone who used Subversion locally on their desktop, with command line mode for the primitive au naturel types. The manual and various example pages talk about this option a lot which was probably good in the early evangelism phase. It could also be that you used the very old exe-installer from Tigris. Possible, I've been using it at work awhile - since version 1.2 or something like that. (longer at home) But in this instance, I seem to remember modifying it manually (a few years back) Either way, I always verify that it is set correctly as a system variable, no matter how it is installed. In any case, I'm not so sure the APR_ICONV_PATH had that much effect on the overall installation. The Python trace only went away when I finally changed the path settings - it looks like Python needs to find the Subversion\bin DLL's no matter what. Hmmm, I can see that detection of these sorts of modified settings can be pretty difficult without some sort of uninstaller info. Maybe that's why so many MSI installers stuff data into the registry The Apache httpd windows installer has a setting for local use versus used by everybody. And they also allow you to install into a non-default folder Looking into the registry, I see the following entry HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Apache\2.2.21 (Default) ReG_SZ (value not set) ServerRootREG_SZc:\Apache\Apache2.2 SharedREG_DWORD0x0001 (1) Perhaps a similar one at HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Subversion\1.7.2 might be in order? At least for any decisions taken during the install. Another thing to consider, is to set up something like a SVN_HOME environment variable, or possibly SUBVERSION_HOME and then you can set %SVN_HOME%\bin into the path and %SVN_HOME%\iconv into APR_ICONV_PATH That way, anyone changing the location of the Subversion install only has to change it in one place, or you can even create a batch file to re-register the new location via the magic of %~dp0 Best Regards, --Bert David Darj z...@alagazam.net 24/11/2011 03:54 PM To Humberto Madeira humberto.made...@trapezegroup.com cc users users@subversion.apache.org Subject Re: Bug: Subversion Windows installer not setting paths correctly Hi again Bert. Today I've tested this on a (almost) clean Win7 installation I had without problems. I did first a clean install to C:\Test\Subversion... APR_ICONV_PATH was set correctly. I also did a install of first 1.6.17 to C:\Program Files\Subversion and then an upgrade to 1.7.1 to C:\Test\Subversion and the only traces of the 1.6.17 install was some licence files and in the PATH environment variable. APR_ICONV_PATH was correct this time too. I noted that APR_ICONV_PATH is set as User environment variable, maybe you did previous installs for another user and that users variable had the value from this install ? I don't know why it's set just for current user. I didn't create the install scripts, just using them and making necessary modifications. Maybe I should change this for upcoming releases. It could also be that you used the very old exe-installer from Tigris. This one (from what I found in the source code in the repository) did set APR_ICONV_PATH for both current user and for system. You can check the environment variables in the registry by running regedit as administrator. For the users the path is HKEY_USERS\userid\Environement and for all users HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment /David ps. Please use Reply to all so subsequent mail is also sent to the list for others to follow and search for solutions. On 2011-11-23 23:36, Humberto Madeira wrote: Hi David, I actually had 2 installs, one was 1.7.0 and the other was 1.7.1 Both previously had Subversion 1.6.x and Python 2.5.x on them, installed on the default path. I had recently decided that since I put all my Apache products under c:\Apache now that Subversion also qualifies as Apache, I should move it under the Apache tree, so to
BDB backend in SVN 1.7.1
Hi, how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some time ago I remember that previous versions of SVN stored almost always a HEAD revision as fulltext, and others as reverse deltas.(except the case when a delta is bigger that fulltext) Was this behavior changed in SVN 1.7? I've looked at the notes about BDB and they don't differ almost at all from SVN 1.4's ones. Of course, I could look into the code more carefully, but my hope was that it wouldn't be a big deal to give me a short answer, if possible. Thanks in advance! Best, Vyacheslav
Re: BDB backend in SVN 1.7.1
Old BDB-backed repositories stored the older revision as fulltext and newer revisions as deltas. Repositories created with or 'svnadmin upgrade'd by 1.6 and newer reverse this for new revisions of files (while making sure not to introduce a dependency loop in the direction of deltas). http://subversion.apache.org/docs/release-notes/1.6#bdb-forward-deltas On Friday, November 25, 2011 1:08 AM, Vyacheslav Zholudev vyacheslav.zholu...@gmail.com wrote: Hi, how does SVN 1.7.1 store fulltext and deltas in the BDB backend? From some time ago I remember that previous versions of SVN stored almost always a HEAD revision as fulltext, and others as reverse deltas.(except the case when a delta is bigger that fulltext) Was this behavior changed in SVN 1.7? I've looked at the notes about BDB and they don't differ almost at all from SVN 1.4's ones. Of course, I could look into the code more carefully, but my hope was that it wouldn't be a big deal to give me a short answer, if possible. Thanks in advance! Best, Vyacheslav
Queries about SVN (Security related)
Dear Sir, We are in the process of selecting SVN system in our company, could you please clarify following points. 1. Restricting branching activity based on roles specified. That is denying branch functionality to users based on there roles. 2. Denying delete/add folder to certain users, it is not just r or r/w. if user has r/w access but shouldn't have delete or add access, only modify commit should be accessible. 3. Is it possible host repos in 2 different physical locations? 4. How to delete folders or file permanently. As of now we are using following software for svn access: Collabnet Subversion Edge 2.0.1 SVN 1.6 Tortoise 1.6. We are using SVN system as trail basis before adapting for entire company. So please clarify above issues. Thanks Regards, Jerryleen S Project Coordinator, PRDC ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Computer viruses or other malware can be transmitted by email. Therefore, please check this email and any attachment(s) for the presence of viruses, malware, etc. The PRDC accepts no liability whatsoever for any damage - whether direct or consequential - caused by any virus, malware, etc. transmitted by this email. **
RE: Queries about SVN (Security related)
-Original Message- From: Jerryleen S [mailto:jerrylee...@prdcinfotech.com] Sent: 25 November 2011 06:32 Subject: Queries about SVN (Security related) Dear Sir, We are in the process of selecting SVN system in our company, could you please clarify following points. 1. Restricting branching activity based on roles specified. That is denying branch functionality to users based on there roles. 2. Denying delete/add folder to certain users, it is not just r or r/w. if user has r/w access but shouldn't have delete or add access, only modify commit should be accessible. This functionality is not baked in. It might well be possible to do with a pre-commit hook but you (your admin team) would need to write and maintain the script. Personally I have not tried to do such things. 3. Is it possible host repos in 2 different physical locations? What do you mean by host? There is built-in support for providing read-only mirrors (also as write-through proxies) but if you want multiple 'master' repositories then you need to look to WanDISCO's proprietry MultiSite extension. 4. How to delete folders or file permanently. I assume you mean remove completely from all history? Ignoring all the arguments about if a source control product should even allow this, it is only currently possible by 'dump', 'dumpfilter' and 'reload'ing the whole repository. It is a feature on the roadmap (http://subversion.apache.org/roadmap.html) called 'obliterate' but not soon. As of now we are using following software for svn access: Collabnet Subversion Edge 2.0.1 SVN 1.6 Tortoise 1.6. We are using SVN system as trail basis before adapting for entire company. So please clarify above issues. I assume you have found and read the online subversion book? http://svnbook.red-bean.com/en/1.7/index.html Thanks Regards, Jerryleen S Project Coordinator, PRDC ** Please consider the environment before printing this email. Do it only if it is absolutely necessary. DISCLAIMER: The contents of this email including attachment(s), if any, are intended for the exclusive use of the addressee(s) and may contain proprietary, confidential or privileged information. If you have received this mail in error, please notify the sender immediately and destroy all copies of this message and any attachment(s).Computer viruses or other malware can be transmitted by email. Therefore, please check this email and any attachment(s) for the presence of viruses, malware, etc. The PRDC accepts no liability whatsoever for any damage - whether direct or consequential - caused by any virus, malware, etc. transmitted by this email. ** ...can you remove the above disclaimer from posts to public mail lists (it makes no sense)? ~ mark c
