Rearranging archive
I have inherited an archive that was created without using the recommended directory structure hosted on a Windows XP box set up with Apache and SSL. Everything works fine except our project is now to the point where I want to start using tags. Since the archives were created without a 'trunk' I don't have a good way to do this. What I would like to do is fix the archive so that the directory structure looks like the recommended. I have not been able to find a way to move the entire repository into a new directory tree so that the code files are in a 'trunk' directory. What I have now is: archive proj1 project files proj2 project files etc. What I want to move to is: new archive proj1 trunk project files tags branches proj2 trunk project files tags branches etc. I'm sure I'm trying to make this harder than it actually is but so far I'm striking out. -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Unable to lock error: what is going on here?
$ svn update svn: Unable to lock 'utscmd' $ svn propget svn:ignore utspkg_src utscmd utslib utsbin utstool utscmd is a subdirectory of the current working directory. It is included in svn:ignore. Why is svn even trying to lock this directory? The sequence of events here is that the project was checked out and then its build command run. The build command created a number of directories, which have been added to svn:ignore so as not to figure in svn at all. What am I failing to understand here? Steve Cohen
Unable to lock error: what is going on here?
$ svn update svn: Unable to lock 'utscmd' $ svn propget svn:ignore utspkg_src utscmd utslib utsbin utstool utscmd is a subdirectory of the current working directory. It is included in svn:ignore. Why is svn even trying to lock this directory? The sequence of events here is that the project was checked out and then its build command run. The build command created a number of directories, which have been added to svn:ignore so as not to figure in svn at all. What am I failing to understand here? Steve Cohen
svn:ignore with recursive and non-recursive patterns
I have a need to define a number of svn:ignore patterns in my project. Some are specific directories somewhere in my project tree. Others are particular file types created by a build process such as *.o which may be found in any number of directories. However, the svn propset command only allows the recursive -R switch to be applied to the entire set of values for the svn:ignore property. Whereas what is needed is to be able to apply the recursive switch to the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore). Is there any way of achieving this? There doesn't appear to be one. Yet without it, svn:ignore is useless, or at least too cumbersome to be used well. Steve Cohen
pattern for specifying svn:ignore for files without extension
The build process of the application I am bringing under svn creates a number of unix binary executables that have no extension : for example abcde fghqp etc. I believe that * will match any files with or without periods so it isn't suitable. Is there a pattern specifier that would embrace all files without an extension? Alternatively, one common differentiating aspect of these files is that they have executable privileges. Being able to svn:ignore based on this would be a nice feature to have.
Re: pattern for specifying svn:ignore for files without extension
On 12/01/2010 02:08 PM, Ryan Schmidt wrote: Redirecting this discussion back to the mailing list.. On Dec 1, 2010, at 14:05, Steve Cohen wrote: On 12/01/2010 01:38 PM, Ryan Schmidt wrote: Can you have the build process write its files to a different directory (a "build" directory) that you could svn:ignore everything in? Sadly, no, not without a major rewrite of the build process. This is deep legacy stuff, using make, with the typical pattern of mixing source and object in the same directory. Not the way I would have designed it but ... Then you may have to set an svn:ignore for each file you want to ignore. It seems to me that svn --recursive propset svn:ignore xyz is basically just syntactic sugar for manually going through issuing svn propset svn:ignore xyz on every node of the directory structure, It is syntactic sugar in the sense that the end product in either case would be the same. There is no "recursive" data attribute in a project's svn:ignore tree. Which leads me to think that a one-time shell script or python script or whatever might be written to walk the directory tree, look for all the executable files and manually add them to that directory's svn:ignore list.
Re: pattern for specifying svn:ignore for files without extension
On 12/01/2010 03:33 PM, Ryan Schmidt wrote:
On Dec 1, 2010, at 15:19, Steve Cohen wrote:
It seems to me that
svn --recursive propset svn:ignore xyz
is basically just syntactic sugar for manually going through issuing
svn propset svn:ignore xyz
on every node of the directory structure, It is syntactic sugar in the sense that the
end product in either case would be the same. There is no "recursive" data
attribute in a project's svn:ignore tree.
Yes, that's right.
Which leads me to think that a one-time shell script or python script or
whatever might be written to walk the directory tree, look for all the
executable files and manually add them to that directory's svn:ignore list.
That should work.
The other approach that initially occurred to me was to clean the directory so there are no unversioned files
("make clean" perhaps), then build the software ("make"), then copy the output of "svn
status" into an editor and massage it a bit to turn it into something you can hand to "svn propset svn:ignore
--file". Though this would have to be done on a per-directory basis, so if there are many directories involved
this may be impractical and a script as you suggest may do better.
Thanks for confirming, this should work, but one more question.
I've already got some other files in svn:ignore in each directory.
There is no command to append a name to the svn:ignore property. So my
script would have to call
svn propget svn:ignore
and then
svn propset svn:ignore
appending the list, right?
Re: svn:ignore with recursive and non-recursive patterns
On 12/02/2010 12:23 AM, Daniel Shahaf wrote: You can use 'propedit --editor-cmd=script.sh **/', where script.sh appends '*.o' to argv[1]. Another example, the following is a "Fix typo in the log message" idiom: % svn propedit --revprop -r69426 --editor-cmd 'sed -i s/foo/bar/' svn:log Steve Cohen wrote on Wed, Dec 01, 2010 at 12:29:58 -0600: I have a need to define a number of svn:ignore patterns in my project. Some are specific directories somewhere in my project tree. Others are particular file types created by a build process such as *.o which may be found in any number of directories. However, the svn propset command only allows the recursive -R switch to be applied to the entire set of values for the svn:ignore property. Whereas what is needed is to be able to apply the recursive switch to the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore). Is there any way of achieving this? There doesn't appear to be one. Yet without it, svn:ignore is useless, or at least too cumbersome to be used well. Steve Cohen Does svn propset svn:ignore accept the **/filename idiom as a legitimate pattern indicating recursion or are you saying that the script would need to manually execute the recursion indicated by the idiom?
Re: svn:ignore with recursive and non-recursive patterns
On 12/01/2010 12:29 PM, Steve Cohen wrote: I have a need to define a number of svn:ignore patterns in my project. Some are specific directories somewhere in my project tree. Others are particular file types created by a build process such as *.o which may be found in any number of directories. However, the svn propset command only allows the recursive -R switch to be applied to the entire set of values for the svn:ignore property. Whereas what is needed is to be able to apply the recursive switch to the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore). Is there any way of achieving this? There doesn't appear to be one. Yet without it, svn:ignore is useless, or at least too cumbersome to be used well. Steve Cohen The following methodology seems to work pretty well in my case: Check out the pristine source TWICE into two local working copies. One one working copy perform the complete build. Against that working copy run a python script based on os.walk that looks for a. executable files b. other generated files of interest c. newly created directories. for each a or b found, use the python subprocess module to invoke svn propget on the mirror of that directory in the second working copy. This is necessary because, svn update and svn commit do not work on a directory tree containing unversioned directories. Check to make sure that the object is not already in the properties, and if not, add it to the list and save it with svn propset. for each c found do the same and then remove it from the dir list that is recursed into by os.walk. Also remove any .svn directories from os.walk without any processing. Now there should be a clean copy of the project ignoring everything that needs to be ignored. I can't help but think there ought to be an easier way, but hey, job security and all that.
Re: Unable to lock error: what is going on here?
On 12/02/2010 08:39 AM, Bob Archer wrote: $ svn update svn: Unable to lock 'utscmd' $ svn propget svn:ignore utspkg_src utscmd utslib utsbin utstool utscmd is a subdirectory of the current working directory. It is included in svn:ignore. Why is svn even trying to lock this directory? The sequence of events here is that the project was checked out and then its build command run. The build command created a number of directories, which have been added to svn:ignore so as not to figure in svn at all. What am I failing to understand here? Are you sure utscmd is not already versioned. Ignores only works on non-versioned files. BOb Yes, that was the problem. The directory was already versioned and it shouldn't have been. The build process then came along and destroyed it (including its .svn subdirectory) and made a new one. However, I still don't understand why svn update is designed to fail if unversioned directories are found below it. Couldn't they just be ignored?
Re: Unable to lock error: what is going on here?
On 12/02/2010 05:24 PM, Bob Archer wrote: On 12/02/2010 08:39 AM, Bob Archer wrote: $ svn update svn: Unable to lock 'utscmd' $ svn propget svn:ignore utspkg_src utscmd utslib utsbin utstool utscmd is a subdirectory of the current working directory. It is included in svn:ignore. Why is svn even trying to lock this directory? The sequence of events here is that the project was checked out and then its build command run. The build command created a number of directories, which have been added to svn:ignore so as not to figure in svn at all. What am I failing to understand here? Are you sure utscmd is not already versioned. Ignores only works on non-versioned files. BOb Yes, that was the problem. The directory was already versioned and it shouldn't have been. The build process then came along and destroyed it (including its .svn subdirectory) and made a new one. However, I still don't understand why svn update is designed to fail if unversioned directories are found below it. Couldn't they just be ignored? try... svn up --force BOb Thanks, Bob.
Re: svn:ignore with recursive and non-recursive patterns
On 12/02/2010 10:23 AM, Steve Cohen wrote: On 12/01/2010 12:29 PM, Steve Cohen wrote: I have a need to define a number of svn:ignore patterns in my project. Some are specific directories somewhere in my project tree. Others are particular file types created by a build process such as *.o which may be found in any number of directories. However, the svn propset command only allows the recursive -R switch to be applied to the entire set of values for the svn:ignore property. Whereas what is needed is to be able to apply the recursive switch to the VALUE(e.g. *.o), not the KEY (e.g. svn:ignore). Is there any way of achieving this? There doesn't appear to be one. Yet without it, svn:ignore is useless, or at least too cumbersome to be used well. Steve Cohen The following methodology seems to work pretty well in my case: Check out the pristine source TWICE into two local working copies. One one working copy perform the complete build. Against that working copy run a python script based on os.walk that looks for a. executable files b. other generated files of interest c. newly created directories. for each a or b found, use the python subprocess module to invoke svn propget on the mirror of that directory in the second working copy. This is necessary because, svn update and svn commit do not work on a directory tree containing unversioned directories. Check to make sure that the object is not already in the properties, and if not, add it to the list and save it with svn propset. for each c found do the same and then remove it from the dir list that is recursed into by os.walk. Also remove any .svn directories from os.walk without any processing. Now there should be a clean copy of the project ignoring everything that needs to be ignored. I can't help but think there ought to be an easier way, but hey, job security and all that. A slightly better (simpler) algorithm: Against that working copy run a python script based on os.walk that looks for a. subdirectories b. files which are not present on the pristine working copy. For every such file or directory found invoke a subprocess that calls svn propget svn:ignore on its parent directory analog in the pristine working copy. If its file name is not already in the list of values returned AND If its file name does not wildcard-match anything in the list of values returned THEN append its name to the list invoke a subprocess that calls svn propset svn:ignore passing in the appended-to list. For every directory found it may be removed from the dirs list returned by os.walk, thus pruning the tree since everything in it will be blocked by its parent directory. Also prune the .svn directories as part of the os.walk There is no need to look for executable files. Any file present in the built working copy and not in the pristine working copy should be ignored. When the script has completed, svn commit may be run against the second working copy.
Letters at beginnings of columns of svn output
Where is this documented? I sometimes see letters I don't know, such as "G", what is that for - and these outputs may differ from command to command. Also the column in which a letter appears is significant. Can someone please point me to a document where this is explained? It's not in the manual except for the status command. Thanks
Re: Letters at beginnings of columns of svn output
On 01/20/2011 04:28 AM, JamieEchlin wrote: Stephen Butler wrote: On the command line, try svn help update (for instance). It's also in the SVN Book's command reference chapter, under the given 'svn' subcommand: There is docn for the letters for status and for update, but I haven't found anything for the output from merge, which have subtle differences from the above two. cheers, jamie exactly my point. It isn't documented for merge. In my google searches I ran across a post where someone complained about this in 2007.
Re: Letters at beginnings of columns of svn output
On 01/20/2011 05:19 AM, Stephen Butler wrote: A 'C' in the third column indicates a tree conflict, while a 'C' in Thanks, Stephen. While we're on the subject, can you tell me succinctly what is the exact definition of a "tree conflict"? This used to drive me nuts when I used the subclipse plugin. I got these all the time and I could never understand them. I've now switched to the subversive Eclipse plugin which is even worse for merging (I've never been able replicate with it merges that are simple on the command line) but better in other respects, and have fallen back on a strategy of doing all merges on the command line which seems to produce better results for the most part. Both plugins assume a great deal of knowledge about the merge process and their "documentation" is restricted to inadequate explanations of what each widget in the plugin does, without explaining in real-world terms i.e. in use cases: When you have scenario x you want to do y, etc. The command line is better documented but even here as we see, there are holes. This question was sparked by the following scenario: I had made a relatively small number of changes in a branch for future development. Among these changes were the additions of several new source files. As I was doing so, a higher-priority defect emerged in production which had to be resolved immediately. I made these changes in the trunk. Naturally, I wanted to merge these changes into my branch. However, no version of the merge command that I could come up with resulted in a situation that did not want to delete the newly added files. My final, unsatisfactory conclusion to this mess, was to do the merge and before committing, revert the files that it wanted to delete. I have a feeling that this was wrong, and that down the line, some future merge will go badly. Steve
Understanding merging
I work with a very senior colleague who has never always resisted version control and would much rather do without it, but he is forced to go along and I am the whipping boy whenever something goes wrong. He poses a general but simple question that I find myself unable to give a simple answer to. I am rephrasing it slightly but it bothers me that I don't know the simple answer. If I found myself in this situation I would tweak until it was as desired, but my persnickety colleague is not satisfied with such answers and for once, I don't blame him. Given two branches off a trunk that were taken at different times, if the first is merged back to the trunk and then the second, how may the second be merged back into the trunk so as not to override changes from the first merge, assuming that both change sets are desired to be in the trunk at the end?
Understanding merging
I work with a very senior colleague who has never always resisted version control and would much rather do without it, but he is forced to go along and I am the whipping boy whenever something goes wrong. He poses a general but simple question that I find myself unable to give a simple answer to. I am rephrasing it slightly but it bothers me that I don't know the simple answer. If I found myself in this situation I would tweak until it was as desired, but my persnickety colleague is not satisfied with such answers and for once, I don't blame him. Given two branches off a trunk that were taken at different times, if the first is merged back to the trunk and then the second, how may the second be merged back into the trunk so as not to override changes from the first merge, assuming that both change sets are desired to be in the trunk at the end? smime.p7s Description: S/MIME Cryptographic Signature
SVN always thinks a few certain files need to be merged
Somewhere back in the distant past, I was a bad bad boy and did something that SVN didn't like to get some merge to work. This happened about two years ago. Since then, these files are picked up for properties merges whenever I merge their project even though they haven't really changed in years. How can I FIX this merge info so I stop being bothered by them. This is really annoying.
Re: SVN always thinks a few certain files need to be merged
On 03/23/2011 05:36 PM, Pat Farrell wrote: Since then, these files are picked up for properties merges whenever I merge their project even though they haven't really changed in years. How can I FIX this merge info so I stop being bothered by them. Wouldn't "svn revert filename" clear this? Or did you want to keep your changes? Nope. I've had the same problem for at least a year. I think it was caused by a bug in the implementation of "merge info" back in 1.5 days. For me, the file in question has not been modified in at least a year. Yet every time I do anything to other files, it is marked as updated. I have no idea how to fix it, but I sure would want to find a solution. Exactly. The files haven't changed in two years. Yet every time I do a merge I encounter them. And all it's about is "merge info". Isn't there some way to get the "merge info" right? There MUST BE.
Re: SVN always thinks a few certain files need to be merged
On 03/23/2011 08:02 PM, David Huang wrote: On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: You are not giving much specifics, so how can people know what is going on in your case? Specifics for complete 100% reproducable problem: do svn update for whole project create branch from trunk change one source file, not the one with the bogus mergeinfo, commit it. merge branch back to trunk before you commit the trunk, do a svn status You will see the bogus mergeinfo listed as a change to the trunk. If you're sure that the mergeinfo is bogus, why not just delete it? e.g., svn propdel svn:mergeinfo fnfapp/src/java/com/fnfbook/bean/FilterListBase.java http://www.collab.net/community/subversion/articles/merge-info.html might be worth a read too. My specifics are substantially similar to those of Mr. Farrell, which are essentially what I laid out in my original post that started this thread. And yet Mr. Kolinko complains I've not given him enough specifics. One specific I can give is that our SVN server is still 1.5.4. Clearly something is broken here. If mergeinfo constantly requires merging when there are no changes, how is that to be fixed? The documents that have been posted here provide way too much information for my use case. I should not need to understand that much of subversion internals to fix this problem! > If you're sure that the mergeinfo is bogus, why not just delete it? Because I'm scared as hell to mess with it! Who KNOWS what the effect of deleting mergeinfo is? Once bitten, twice-shy. What side-effects deleting mergeinfo will have? Can someone explain that to me? If someone can tell me what the effects of deleting mergeinfo will be I would be willing to try it.
Re: SVN always thinks a few certain files need to be merged
On 03/23/2011 08:09 PM, Pat Farrell wrote: On 03/23/2011 09:02 PM, David Huang wrote: If you're sure that the mergeinfo is bogus, why not just delete it? e.g., svn propdel svn:mergeinfo fnfapp/src/java/com/fnfbook/bean/FilterListBase.java I'm sure. I'll try that. I have not tried it before, because I can't figure out what in the heck mergeinfo was supposed to do, and there have been lots of comments that it really didn't work properly in 1.5, and that it works differently in 1.6, etc. in other words, I didn't know to do that. Or even that such as command existed. For me, blowing up all mergeinfo would improve SVN. propset/propedit/propdel is opaque to me, everytime I try to use it, I spend an hour dorking around trying random combination of specs, directories, etc. Again, the SVN gurus need to listen to Mr. Farrell and myself here. Ordinary users should not be required to understand mergeinfo at the level that is being presented here. What is it? Why is it needed? If it gets screwed up, and you delete it, what are you losing? You must be losing something, else why have it in the first place? It's not right to suggest simply getting rid of it without explaining the full consequences of that action. This is how I got in trouble in the first place. Have to agree with Mr. Farrell: > For me, blowing up all mergeinfo would improve SVN. > > propset/propedit/propdel is opaque to me, everytime I try to use it, I > spend an hour dorking around trying random combination of specs, > directories, etc. Unless the pros here can do better than they've done in explaining this whole area is a real black eye for SVN. My repository is still at 1.5.4. I can have my SCM team upgrade me to 1.6.something. Should I do this, and would it help this problem?
Re: SVN always thinks a few certain files need to be merged
On 03/24/2011 05:01 PM, Bob Archer wrote: On 03/23/2011 08:02 PM, David Huang wrote: On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: You are not giving much specifics, so how can people know what is going on in your case? Specifics for complete 100% reproducable problem: do svn update for whole project create branch from trunk change one source file, not the one with the bogus mergeinfo, commit it. merge branch back to trunk before you commit the trunk, do a svn status You will see the bogus mergeinfo listed as a change to the trunk. If you're sure that the mergeinfo is bogus, why not just delete it? e.g., svn propdel svn:mergeinfo fnfapp/src/java/com/fnfbook/bean/FilterListBase.java http://www.collab.net/community/subversion/articles/merge- info.html might be worth a read too. My specifics are substantially similar to those of Mr. Farrell, which are essentially what I laid out in my original post that started this thread. And yet Mr. Kolinko complains I've not given him enough specifics. One specific I can give is that our SVN server is still 1.5.4. Clearly something is broken here. If mergeinfo constantly requires merging when there are no changes, how is that to be fixed? The documents that have been posted here provide way too much information for my use case. I should not need to understand that much of subversion internals to fix this problem! Basically, what it comes down to is the fact that the merge info on the files does not match the merge info on the parent folders. Whenever and item in the path has mergeinfo and a merge is performed that merge info is updated. (this is supposed to stop happening as of 1.7 I believe). As long as there is merge info on a file that isn't in the parent folder the merge info will remain at the file level. Once they match the merge info in the children (files) will be elided and you won't see this happen again. I assume every time you see these property changes you are committing them? BOb Yes, and thanks. What I take from your explanation is that removing the merge info from these files is both safe and effective in getting where I want to go (not be bothered by this anymore). Is that right? Is there any downside?
Re: SVN always thinks a few certain files need to be merged
On 03/24/2011 05:11 PM, Bob Archer wrote: On 03/24/2011 05:01 PM, Bob Archer wrote: On 03/23/2011 08:02 PM, David Huang wrote: On Mar 23, 2011, at 7:52 PM, Pat Farrell wrote: On 03/23/2011 08:34 PM, Konstantin Kolinko wrote: You are not giving much specifics, so how can people know what is going on in your case? Specifics for complete 100% reproducable problem: do svn update for whole project create branch from trunk change one source file, not the one with the bogus mergeinfo, commit it. merge branch back to trunk before you commit the trunk, do a svn status You will see the bogus mergeinfo listed as a change to the trunk. If you're sure that the mergeinfo is bogus, why not just delete it? e.g., svn propdel svn:mergeinfo fnfapp/src/java/com/fnfbook/bean/FilterListBase.java http://www.collab.net/community/subversion/articles/merge- info.html might be worth a read too. My specifics are substantially similar to those of Mr. Farrell, which are essentially what I laid out in my original post that started this thread. And yet Mr. Kolinko complains I've not given him enough specifics. One specific I can give is that our SVN server is still 1.5.4. Clearly something is broken here. If mergeinfo constantly requires merging when there are no changes, how is that to be fixed? The documents that have been posted here provide way too much information for my use case. I should not need to understand that much of subversion internals to fix this problem! Basically, what it comes down to is the fact that the merge info on the files does not match the merge info on the parent folders. Whenever and item in the path has mergeinfo and a merge is performed that merge info is updated. (this is supposed to stop happening as of 1.7 I believe). As long as there is merge info on a file that isn't in the parent folder the merge info will remain at the file level. Once they match the merge info in the children (files) will be elided and you won't see this happen again. I assume every time you see these property changes you are committing them? BOb Yes, and thanks. What I take from your explanation is that removing the merge info from these files is both safe and effective in getting where I want to go (not be bothered by this anymore). Is that right? It's not that simple, but it can be. My question would be.. what is the difference between the mergeinfo on these files and the merge info on your project root (which is where you should always perform your merges for this to work best). Once you know the difference the question is "why are they different". If it was due to a bug in svn then you should be ok with some manual changes. If it is due to some revision not being merged in at the project root level then I would ask, why aren't they merged at the root level? Is there any downside? Only you can answer that based on doing the above investigation. If you don't remove needed mergeinfo then there is no downside. ;) BOb I probably did many things when I was learning this stuff that wouldn't do now. But my punishment shouldn't be eternal. Thanks.
Windows SSL Error
Our Entrust SSL certificate recently expired and was replaced with a new one utilizing a certificate chain. Since installing the new certificate, access to a front-end website using this same certificate has been unaffected. However, we're now seeing issues when we attempt to check out/update/browse/etc the repository using Windows (XP/7). In Windows, using version 1.6.16, I'm getting the following error: C:\Users\steve_platz>svn info https://path/to/repository Error validating server certificate for 'https://path/to/repository:443': - The certificate is not issued by a trusted authority. Use the fingerprint to validate the certificate manually! Certificate information: - Hostname: my.website.com - Valid: from Mon, 18 Apr 2011 18:52:34 GMT until Fri, 05 Jun 2015 23:15:02 GMT - Issuer: (c) 2009 Entrust, Inc., www.entrust.net/rpa is incorporated by reference, Entrust, Inc., US - Fingerprint: 96:b4:fa:19:bd:4a:ec:c2:bc:19:33:b8:25:2a:0a:47:28:41:07:d0 (R)eject, accept (t)emporarily or accept (p)ermanently? T Running the above (svn info) from a Linux machine works as you would expect it to, without certificate errors. Is this a bug with the Windows client or have I set something up incorrectly? Thanks for your help! Steve Platz
RE: Windows SSL Error
For those Linux servers that I've tried this on, the ~/.subversion/servers file is the default one that is created with a brand new install. There are no entries under [global] or [groups]. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, April 26, 2011 3:49 PM To: Platz, Steve Cc: users@subversion.apache.org Subject: Re: Windows SSL Error On Tue, Apr 26, 2011 at 6:06 PM, Platz, Steve wrote: > Our Entrust SSL certificate recently expired and was replaced with a > new one utilizing a certificate chain. Since installing the new > certificate, access to a front-end website using this same certificate has > been unaffected. > However, we're now seeing issues when we attempt to check > out/update/browse/etc the repository using Windows (XP/7). In Windows, > using version 1.6.16, I'm getting the following error: > > > > C:\Users\steve_platz>svn info > https://path/to/repository > > Error validating server certificate for 'https://path/to/repository:443': > > - The certificate is not issued by a trusted authority. Use the > fingerprint to validate the certificate manually! > > Certificate information: > > - Hostname: my.website.com > > - Valid: from Mon, 18 Apr 2011 18:52:34 GMT until Fri, > 05 Jun > 2015 23:15:02 GMT > > > > - Issuer: (c) 2009 Entrust, Inc., www.entrust.net/rpa > is incorporated by reference, Entrust, Inc., US > > - Fingerprint: > 96:b4:fa:19:bd:4a:ec:c2:bc:19:33:b8:25:2a:0a:47:28:41:07:d0 > > (R)eject, accept (t)emporarily or accept (p)ermanently? T > > > > Running the above (svn info) from a Linux machine works as you would > expect it to, without certificate errors. Is this a bug with the > Windows client or have I set something up incorrectly? Just guessing, but maybe the Linux machine (only your account, or system-wide) has been configured to trust the Issuer's certificate as a trusted certificate authority (thus automatically trusting every certificate issued by that CA), and your Windows machine hasn't. This can be configured on the client side, with the property ssl-authority-files - For the user in ~/.subversion/servers - System-wide in /etc/subversion/servers See for more info: http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn.advanced.confarea.opts.servers You can do the same on Windows (also system-wide, I think that only works via the Registry, but see the book for more details). HTH, -- Johan
RE: Windows SSL Error
Same thing there as well. -Original Message- From: Johan Corveleyn [mailto:jcor...@gmail.com] Sent: Tuesday, April 26, 2011 4:15 PM To: Platz, Steve Cc: users@subversion.apache.org Subject: Re: Windows SSL Error And what about the system-wide file then? /etc/subversion/servers? On Tue, Apr 26, 2011 at 9:53 PM, Platz, Steve wrote: > For those Linux servers that I've tried this on, the ~/.subversion/servers > file is the default one that is created with a brand new install. There are > no entries under [global] or [groups]. > > -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Tuesday, April 26, 2011 3:49 PM > To: Platz, Steve > Cc: users@subversion.apache.org > Subject: Re: Windows SSL Error > > On Tue, Apr 26, 2011 at 6:06 PM, Platz, Steve wrote: >> Our Entrust SSL certificate recently expired and was replaced with a >> new one utilizing a certificate chain. Since installing the new >> certificate, access to a front-end website using this same certificate has >> been unaffected. >> However, we're now seeing issues when we attempt to check >> out/update/browse/etc the repository using Windows (XP/7). In >> Windows, using version 1.6.16, I'm getting the following error: >> >> >> >> C:\Users\steve_platz>svn info >> https://path/to/repository >> >> Error validating server certificate for 'https://path/to/repository:443': >> >> - The certificate is not issued by a trusted authority. Use the >> fingerprint to validate the certificate manually! >> >> Certificate information: >> >> - Hostname: my.website.com >> >> - Valid: from Mon, 18 Apr 2011 18:52:34 GMT until Fri, >> 05 Jun >> 2015 23:15:02 GMT >> >> >> >> - Issuer: (c) 2009 Entrust, Inc., www.entrust.net/rpa >> is incorporated by reference, Entrust, Inc., US >> >> - Fingerprint: >> 96:b4:fa:19:bd:4a:ec:c2:bc:19:33:b8:25:2a:0a:47:28:41:07:d0 >> >> (R)eject, accept (t)emporarily or accept (p)ermanently? T >> >> >> >> Running the above (svn info) from a Linux machine works as you would >> expect it to, without certificate errors. Is this a bug with the >> Windows client or have I set something up incorrectly? > > Just guessing, but maybe the Linux machine (only your account, or > system-wide) has been configured to trust the Issuer's certificate as a > trusted certificate authority (thus automatically trusting every certificate > issued by that CA), and your Windows machine hasn't. > > This can be configured on the client side, with the property > ssl-authority-files > - For the user in ~/.subversion/servers > - System-wide in /etc/subversion/servers > > See for more info: > http://svnbook.red-bean.com/nightly/en/svn.advanced.confarea.html#svn. > advanced.confarea.opts.servers > > You can do the same on Windows (also system-wide, I think that only works via > the Registry, but see the book for more details). > > HTH, > -- > Johan > -- Johan
RE: Windows SSL Error
That was one of my first thoughts as well. I checked my root certificate store and the Entrust certificate that seems to be having problems is in there. Steve -Original Message- From: Konstantin Kolinko [mailto:knst.koli...@gmail.com] Sent: Friday, April 29, 2011 5:25 PM To: Platz, Steve Cc: users@subversion.apache.org Subject: Re: Windows SSL Error 2011/4/26 Platz, Steve : > Our Entrust SSL certificate recently expired and was replaced with a > new one utilizing a certificate chain. Since installing the new > certificate, access to a front-end website using this same certificate has > been unaffected. > However, we're now seeing issues when we attempt to check > out/update/browse/etc the repository using Windows (XP/7). In Windows, > using version 1.6.16, I'm getting the following error: > > > > C:\Users\steve_platz>svn info > https://path/to/repository > > Error validating server certificate for 'https://path/to/repository:443': > > - The certificate is not issued by a trusted authority. Use the > fingerprint to validate the certificate manually! > I think that it uses OS libraries to check the certificates. When you go to the Microsoft's Windows update site, among the "not important" updates there exists the "update root certificates" update. Maybe it will help you. Quick googling leads to this page: http://support.microsoft.com/kb/931125/en-us Best regards, Konstantin Kolinko
differencing only header files
Is there an easy way to restrict svn diff operation to files of a certain extension (say .h)? A quick glance at the manual suggested nothing to me.
How to turn off svn:executable from /etc/subversion/config
I want to turn OFF the svn:executable property for many file types from inside /etc/subversion/config. Is there a way to do this? The documentation for this property says that its existence will force its value to "*". I want to be able to specify something like: README= svn:eol-style=native; svn:mime-type=text/plain; svn:executable=false Is there a way to do this? Thanks, Steve
Re: How to turn off svn:executable from /etc/subversion/config
I agree, lots of files *shouldn't* be marked executable, but lots of users just don't care. I'm trying to protect everyone else from their sloppiness. That's why I'd like to turn svn:executable off with the autoprops. If someone *really* needs svn:executable on some file that shouldn't normally have that prop, they can always override it. Steve P.S. I poked around a little in the 1.7.2 code, trying to find out where the property was set to "*" regardless of its real setting, but it didn't pop out. Daniel Shahaf said the following on 01/09/2012 05:08 PM: > You can't do this with autoprops. (See auto_props_enumerator() in > libsvn_client/add.c; and notice the output of a manual 'svn propset > svn:executable false'.) Feel free to file a bug about this, and/or > submit a patch implementing this. > > Concretely, though, README shouldn't be marked executable in the first > place. So I suspect the _real_ answer for you is "On Cygwin, use the > native Cygwin svn client rather than the Windows one.". :-) > > On Mon, Jan 9, 2012, at 10:26, Steve Kelem wrote: >> I want to turn OFF the svn:executable property for many file types from >> inside /etc/subversion/config. >> Is there a way to do this? The documentation for this property says that its >> existence will force its value to "*". >> I want to be able to specify something like: >> README= svn:eol-style=native; svn:mime-type=text/plain; >> svn:executable=false >> >> Is there a way to do this? >> >> Thanks, >> Steve >> >>
test for whether a file has been checked in?
Is there a subversion command that I can use in a shell or Perl script to test whether a file or directory has been checked in? Steve
switch to ignore files that have not been checked in?
I'm trying to add properties to a bunch of files that have a common file extension, but are not the only files in the directory/directories. I would like to run something like: svn propset svn:needs-lock '*' *.png *.jpg *.vsd The problem is that I have a number of temporary files in the working directory that match the pattern but are not and should not be checked in. The problem with using the convenience of shell patterns is that subversion aborts as soon as it processes a file that is not already checked in. It also aborts even if a file or directory has the svn:ignore property set. I don't know of an easy way to match all the files that match a shell pattern and are also already checked in. (Which would be a clunky workaround for not having the following:) I'd like to use a switch such as: svn --ignore-non-checked-in-files propset svn:needs-lock '*' *.png *.jpg *.vsd Does such a switch already exist? Such a switch would tell subversion commands to silently ignore files and directories that have not been checked in. The opposite already exists. If I run svn add *.png, the "svn add" command runs, but complains harmlessly if a file has already been checked in. "svn add" does not halt if it encounters a file that has already been checked in. Thanks for your help, Steve
Merging a vendor branch that's also in subversion
My subversion-based project is based on a third-party project that is also stored in subversion, although on a separate server (to which we only have client access). We will soon need to merge the recent changes from the third-party project back into our own codebase. I am preparing to do a merge using the "vendor branch" technique from the svn book, but I was hoping that since both projects are stored in subversion, there might be a simpler way - are there any other options? Thanks, Steve
Re: Merging a vendor branch that's also in subversion
On Fri, Mar 2, 2012 at 2:25 PM, Stefan Sperling wrote: > On Fri, Mar 02, 2012 at 02:01:58PM -0500, Steve Lustbader wrote: > > My subversion-based project is based on a third-party project that is > also > > stored in subversion, although on a separate server (to which we only > have > > client access). We will soon need to merge the recent changes from the > > third-party project back into our own codebase. I am preparing to do a > > merge using the "vendor branch" technique from the svn book, but I was > > hoping that since both projects are stored in subversion, there might be > a > > simpler way - are there any other options? > > Another option might be a foreign repository merge. > Quoting from near the bottom of 'svn help merge' output: > >- Merging from foreign repositories - > > Subversion does support merging from foreign repositories. > While all merge source URLs must point to the same repository, the merge > target working copy may come from a different repository than the source. > However, there are some caveats. Most notably, copies made in the > merge source will be transformed into plain additions in the merge > target. Also, merge-tracking is not supported for merges from foreign > repositories. > Thanks, that looks like exactly what I wanted, so I'll give it a shot. -Steve
Bad URL passed to RA layer: Unrecognized URL scheme
Running this perl script: use SVN::Client; my $svn = new SVN::Client(); $svn->ls( "https://dag-vcs.garmin.com/svn/";, 'HEAD', 0 ); Produces the following error: Bad URL passed to RA layer: Unrecognized URL scheme for 'https://dag-vcs.garmin.com/svn' at test.pl line 3 When run in the following environment: Mac OS X 10.8.2 Perl 5.12.4 Alien-SVN-v1.7.3.1 However, it works fine in this environment: Mac OS X 10.8.2 Perl 5.12.4 Alien-SVN-v1.6.12.1 Note the only difference is SVN 1.6 vs 1.7 in the Alien SVN perl module. Am I doing something wrong or is this a bug? BTW, I already contacted the Alien SVN developer and he said the error is coming from SVN. Thanks, Steve This e-mail and any attachments may contain confidential material for the sole use of the intended recipient. If you are not the intended recipient, please be aware that any disclosure, copying, distribution or use of this e-mail or any attachment is prohibited. If you have received this e-mail in error, please contact the sender and delete all copies. Thank you for your cooperation.
Changed files overwritten with old version upon commit
I have a strange scenario: We are two developers that use an SVN repository to coordinate code releases. I pull down the repository daily, often several times a day. I recently committed to the server and it "blew away" my coworker¹s changes, without any sort of conflict. Like not a few lines of code, but a hundred or so. This has happened twice now on two separate occasions both recent. Here's the catch: I actually saw in my local dev some of the code that got blown away by my most recent commit. So the code must have been in my local repository prior to committing. Any way to check this? Local logs or anything? I am using version 1.6.5 and the svn server is on Unfuddle. Any ideas how or why it would have overwritten the file with an older version upon committing? Also, any ideas where the problem may lay: my svn client, coworker's svn client, or Unfuddle? I'm happy to provide any additional details anyone thinks may be helpful. MUCH thanks in advance, Steve Calamia
Re: Rearranging archive
Thanks for the response. This I can do. However, what I want is to get all of the history etc. into the trunk so that it looks like the repository was created properly to start with. The svn mkdir and mv commands do not work in the repository itself, only in the working copy. Is it possible to re-arrange the existing repository and preserve all of the history/revisions. Something like: svnadmin dump proj1 > dumpfile svnadmin create new/proj1_with_trunk svnadmin load new/proj1_with_trunk < dumpfile I have tried the above but can't seem to get the job done. Is there a way? Ryan Schmidt wrote: On Apr 27, 2010, at 18:43, Steve wrote: I have inherited an archive a repository? that was created without using the recommended directory structure hosted on a Windows XP box set up with Apache and SSL. Everything works fine except our project is now to the point where I want to start using tags. Since the archives were created without a 'trunk' I don't have a good way to do this. What I would like to do is fix the archive so that the directory structure looks like the recommended. I have not been able to find a way to move the entire repository into a new directory tree so that the code files are in a 'trunk' directory. What I have now is: archive proj1 project files proj2 project files etc. What I want to move to is: new archive proj1 trunk project files tags branches proj2 trunk project files tags branches etc. I'm sure I'm trying to make this harder than it actually is but so far I'm striking out. Yup, it's a simple set of svn mkdir and svn mv commands. Consider this pseudo-bash-code: foreach PROJECT svn checkout url://to/repo/PROJECT cd PROJECT svn mkdir trunk branches tags foreach ITEM that is not trunk branches or tags svn mv ITEM trunk done svn commit -m "create trunk branches tags for PROJECT" cd .. rm -rf PROJECT done No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2838 - Release Date: 04/27/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Re: Rearranging archive
I've tried that with every combination of file://... I can think of and I keep getting errors. the disk layout is: drive D (Windows XP) d:\archive - normal directory under archive there are multiple repositories, each representing a separate project. I've created a new repository svnadmin create d:\MyArchive I created a directory tree to mirror what I want: d:\temp d:\temp\proj1 d:\temp\proj1\trunk d:\temp\proj1\branches d:\temp\proj1\tags d:\temp\proj2 d:\temp\proj2\trunk d:\temp\proj2\branches d:\temp\proj2\tags ... From d:\temp I ran svn import . file:///MyArchive svn list file:///MyArchive shows the project files Now, how do I get d:\archive\proj1 into d:\MyArchive\proj1\trunk? Here is what I am getting D:\archive>svn mv file:///archive/proj1 file:///MyArchive/proj1/trunk svn: Source and dest appear not to be in the same repository (src: 'file:///archive/crbuild'; dst: 'file:///MyArchive/crbuild/trunk') Bob Archer wrote: Thanks for the response. This I can do. However, what I want is to get all of the history etc. into the trunk so that it looks like the repository was created properly to start with. The svn mkdir and mv commands do not work in the repository itself, only in the working copy. Sure they do... check out svn help mv: SRC and DST can both be working copy (WC) paths or URLs: WC -> WC: move and schedule for addition (with history) URL -> URL: complete server-side rename. All the SRCs must be of the same type. The mv will retain all the history. If you are on windows you can use the TortoiseSVN repo browser. It makes stuff like this very easy. BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2839 - Release Date: 04/27/10 14:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Re: Rearranging archive
Still no go. D:\archive>svn mkdir file:///d:/archive/crbuild/trunk -m"Create trunk directory" Committed revision 45. D:\archive>svn mv file:///d:/archive/crbuild/* file:///d:/archive/crbuild/trunk svn: Path 'file:///d:/archive/crbuild/*' does not exist in revision 45 Bob Archer wrote: Bob Archer wrote: Thanks for the response. This I can do. However, what I want is to get all of the history etc. into the trunk so that it looks like the repository was created properly to start with. The svn mkdir and mv commands do not work in the repository itself, only in the working copy. Sure they do... check out svn help mv: SRC and DST can both be working copy (WC) paths or URLs: WC -> WC: move and schedule for addition (with history) URL -> URL: complete server-side rename. All the SRCs must be of the same type. The mv will retain all the history. If you are on windows you can use the TortoiseSVN repo browser. It makes stuff like this very easy. BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2839 - Release Date: 04/27/10 14:27:00 I've tried that with every combination of file://... I can think of and I keep getting errors. the disk layout is: drive D (Windows XP) d:\archive - normal directory under archive there are multiple repositories, each representing a separate project. I've created a new repository svnadmin create d:\MyArchive I created a directory tree to mirror what I want: d:\temp d:\temp\proj1 d:\temp\proj1\trunk d:\temp\proj1\branches d:\temp\proj1\tags d:\temp\proj2 d:\temp\proj2\trunk d:\temp\proj2\branches d:\temp\proj2\tags ... From d:\temp I ran svn import . file:///MyArchive svn list file:///MyArchive shows the project files Now, how do I get d:\archive\proj1 into d:\MyArchive\proj1\trunk? Here is what I am getting D:\archive>svn mv file:///archive/proj1 file:///MyArchive/proj1/trunk svn: Source and dest appear not to be in the same repository (src: 'file:///archive/crbuild'; dst: 'file:///MyArchive/crbuild/trunk') Ok, you can't svn mv from one repo to another. Why do you want another repo? Just move within the same repo: D:\archive>svn mv file:///archive/proj1/* file:///archive/proj1/trunk BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2840 - Release Date: 04/28/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Re: Rearranging archive
I have had trouble in the past using Tortoise on the server then accessing the repository over the internet. There seems to be a lot of dependency on versions. I currently am using 1.4.4 with Apache 2.2.4. When the person who initially loaded the archive did it he was using Tortoise with a network mounted drive and we found that the file format value (in the format file) was not compatible with the server setup. Currently, format contains a 5. Can I use the latest Tortoise or do I need to load an older one? BTW, thanks for your patience. This is my first attempt at setting up and administering subversion and I realize some (if not all) questions are basic. I have looked over the documentation but because the repository was not set up according to the recommended structure, things don't seem to work as they I expect. Bob Archer wrote: Since you're on windows I really suggest installing tortoiseSVN... open your repository with the repo browser and you can drag and drop folder/files around in your repo just like you can your file system in Explorer. BOb -Original Message----- From: Steve Kelley [mailto:skel...@sciend.com] Sent: Wednesday, April 28, 2010 12:05 PM To: Bob Archer Cc: Ryan Schmidt; users@subversion.apache.org Subject: Re: Rearranging archive Still no go. D:\archive>svn mkdir file:///d:/archive/crbuild/trunk -m"Create trunk directory" Committed revision 45. D:\archive>svn mv file:///d:/archive/crbuild/* file:///d:/archive/crbuild/trunk svn: Path 'file:///d:/archive/crbuild/*' does not exist in revision 45 Bob Archer wrote: Bob Archer wrote: Thanks for the response. This I can do. However, what I want is to get all of the history etc. into the trunk so that it looks like the repository was created properly to start with. The svn mkdir and mv commands do not work in the repository itself, only in the working copy. Sure they do... check out svn help mv: SRC and DST can both be working copy (WC) paths or URLs: WC -> WC: move and schedule for addition (with history) URL -> URL: complete server-side rename. All the SRCs must be of the same type. The mv will retain all the history. If you are on windows you can use the TortoiseSVN repo browser. It makes stuff like this very easy. BOb -- -- No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2839 - Release Date: 04/27/10 14:27:00 I've tried that with every combination of file://... I can think of and I keep getting errors. the disk layout is: drive D (Windows XP) d:\archive - normal directory under archive there are multiple repositories, each representing a separate project. I've created a new repository svnadmin create d:\MyArchive I created a directory tree to mirror what I want: d:\temp d:\temp\proj1 d:\temp\proj1\trunk d:\temp\proj1\branches d:\temp\proj1\tags d:\temp\proj2 d:\temp\proj2\trunk d:\temp\proj2\branches d:\temp\proj2\tags ... From d:\temp I ran svn import . file:///MyArchive svn list file:///MyArchive shows the project files Now, how do I get d:\archive\proj1 into d:\MyArchive\proj1\trunk? Here is what I am getting D:\archive>svn mv file:///archive/proj1 file:///MyArchive/proj1/trunk svn: Source and dest appear not to be in the same repository (src: 'file:///archive/crbuild'; dst: 'file:///MyArchive/crbuild/trunk') Ok, you can't svn mv from one repo to another. Why do you want another repo? Just move within the same repo: D:\archive>svn mv file:///archive/proj1/* file:///archive/proj1/trunk BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2840 - Release Date: 04/28/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131 No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2840 - Release Date: 04/28/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Re: Rearranging archive
I'm using file:// 'cause all of the setup instructions I found for using svn over SSH that I saw do it that way. Our setup is a 'file server' which I access over the internet using SSH while the others who use it are on the server's local network. Everything is locked down pretty tight, there is no http access, only https. What do you suggest? Bob Archer wrote: I have had trouble in the past using Tortoise on the server then accessing the repository over the internet. There seems to be a lot of dependency on versions. I currently am using 1.4.4 with Apache 2.2.4. When the person who initially loaded the archive did it he was using Tortoise with a network mounted drive and we found that the file format value (in the format file) was not compatible with the server setup. Currently, format contains a 5. Can I use the latest Tortoise or do I need to load an older one? BTW, thanks for your patience. This is my first attempt at setting up and administering subversion and I realize some (if not all) questions are basic. I have looked over the documentation but because the repository was not set up according to the recommended structure, things don't seem to work as they I expect. Ok, I see the problem... I set up a repo and tested this my self. If you try to copy it all to trunk then there is a problem. I was able to move the folders/files one at a time. Like this: svn mkdir file:///c:/Users/Development/TestRepository svn mv file:///c:/Users/Development/TestRepository/folder1 file:///c:/Users/Development/TestRepository/trunk repeat for each folder/file in the root of your project. Here is another way... you will need svnadmin to do it... You well need to create a new empty repository... mkdir TempDump cd TempDump svnadmin dump c:/Users/Development/TestRepositry > MyRepo svnadmin load --parent-dir c:/Users/Development/NewRepository/Trunk < MyRepo Ah yes, you have to be careful with versions. I really suggest you use 1.6 for everything. Also, you really shouldn't be using the file:// protocol on shared repositories. BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2840 - Release Date: 04/28/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Re: Rearranging archive
I installed TortoiseSVN taking a chance that I might have to uninstall it and fix the archive but it works and my remote machine can check out/in files. I guess I should have not been so cautious before. All is now well. Thanks for your help and insights. Bob Archer wrote: I have had trouble in the past using Tortoise on the server then accessing the repository over the internet. There seems to be a lot of dependency on versions. I currently am using 1.4.4 with Apache 2.2.4. When the person who initially loaded the archive did it he was using Tortoise with a network mounted drive and we found that the file format value (in the format file) was not compatible with the server setup. Currently, format contains a 5. Can I use the latest Tortoise or do I need to load an older one? BTW, thanks for your patience. This is my first attempt at setting up and administering subversion and I realize some (if not all) questions are basic. I have looked over the documentation but because the repository was not set up according to the recommended structure, things don't seem to work as they I expect. Ok, I see the problem... I set up a repo and tested this my self. If you try to copy it all to trunk then there is a problem. I was able to move the folders/files one at a time. Like this: svn mkdir file:///c:/Users/Development/TestRepository svn mv file:///c:/Users/Development/TestRepository/folder1 file:///c:/Users/Development/TestRepository/trunk repeat for each folder/file in the root of your project. Here is another way... you will need svnadmin to do it... You well need to create a new empty repository... mkdir TempDump cd TempDump svnadmin dump c:/Users/Development/TestRepositry > MyRepo svnadmin load --parent-dir c:/Users/Development/NewRepository/Trunk < MyRepo Ah yes, you have to be careful with versions. I really suggest you use 1.6 for everything. Also, you really shouldn't be using the file:// protocol on shared repositories. BOb No virus found in this incoming message. Checked by AVG - www.avg.com Version: 9.0.814 / Virus Database: 271.1.1/2840 - Release Date: 04/28/10 02:27:00 -- Steve Kelley 106 Oklahoma Ave. Oak Ridge, TN 37830 865 482 7131
Strange status if .svn folder removed
Hello all, I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 command-line binaries. I have a working copy checked out (C:\wc). Inside it, there's an empty folder that's source-controlled (C:\wc\logs). If I delete the .svn folder from within logs, then doing an "svn st" in the base folder (C:\wc) gives me: C:\wc>svn st ~ log Trying to update to "bring back" the folder shows a delete: C:\wc>svn up Dlog Updated to revision 200374. The folder is still there, without a .svn folder inside it, and svn doesn't know what to do with it. C:\wc>svn st ? log At this point, the repository still shows the folder (the delete didn't happen on the server). After deleting the log folder, svn thinks everything's fine (even though the folder is now totally missing from the working copy) C:\wc>svn st Reverting the folder to bring it back does nothing: C:\wc>svn revert log Skipped 'log' Doing a general update doesn't work: C:\wc>svn up At revision 200376. Only by doing an update directly to log can I get the folder back: C:\wc>svn up log Alog Updated to revision 200376. There are reasons that I probably shouldn't have this skeleton under source control in the first place, but this seems like broken behavior regardless. Should I file it as a bug? Or is it already known? Thanks Steve Armstrong
Re: Strange status if .svn folder removed
Wow, that was a fast reply. Ok, I'll just work around it for now then. Thanks for getting back to me. On Wed, May 26, 2010 at 5:16 PM, Hyrum K. Wright < hyrum_wri...@mail.utexas.edu> wrote: > > > On Wed, May 26, 2010 at 4:06 PM, Steve Armstrong < > steve.armstr...@gmail.com> wrote: > >> Hello all, >> >> I'm seeing strange behaviour on a Win7_64 machine running the 1.6.9 >> command-line binaries. >> >> I have a working copy checked out (C:\wc). Inside it, there's an empty >> folder that's source-controlled (C:\wc\logs). If I delete the .svn folder >> from within logs, then doing an "svn st" in the base folder (C:\wc) gives >> me: >> >> C:\wc>svn st >> ~ log >> >> Trying to update to "bring back" the folder shows a delete: >> C:\wc>svn up >> Dlog >> Updated to revision 200374. >> >> The folder is still there, without a .svn folder inside it, and svn >> doesn't know what to do with it. >> C:\wc>svn st >> ? log >> >> At this point, the repository still shows the folder (the delete didn't >> happen on the server). After deleting the log folder, svn thinks >> everything's fine (even though the folder is now totally missing from the >> working copy) >> >> C:\wc>svn st >> >> Reverting the folder to bring it back does nothing: >> C:\wc>svn revert log >> Skipped 'log' >> >> Doing a general update doesn't work: >> C:\wc>svn up >> At revision 200376. >> >> Only by doing an update directly to log can I get the folder back: >> C:\wc>svn up log >> Alog >> Updated to revision 200376. >> >> There are reasons that I probably shouldn't have this skeleton under >> source control in the first place, but this seems like >> broken behavior regardless. Should I file it as a bug? Or is it already >> known? >> > > I wouldn't file a bug. Per-directory .svn directories are disappearing in > 1.7, and it's unlikely that the bug (if that's what it is) would be address > specifically for the 1.6.x line. > > -Hyrum >
Question about pysvn installer for Windows
I don't know if this question belongs here or not but in any case, any advice is appreciated Originally posted on tigris.org On Jun 28, 2010, at 10:30 AM, Steve Johnson wrote: > > I'm not sure this is the correct place to ask this question. Briefly, I am trying to install pysvn using the py26-pysvn-svn156-1.7.1-1233.exe Windows installer. I get an error about Python2.6 not being installe but it is installed (by Cygwin) and it's in my PATH so I wonder what your installer "thinks" it needs to detect Python. > > > > Where can I find help with this? The best place for this question would be the users@subversion.apache.org list. Subversion, like all Tigris projects, maintains its own mail lists, help resources, and knowledge base. The list you contacted, feedb...@tigris, is only involved in whole-site matters, like maintenance and down-time. -==- Jack Repenning jackrepenn...@tigris.org Domain Administrator http://www.tigris.org -- Steve Johnson, Senior Content Developer Caringo ste...@caringo.com
svnserve segmentation fault under Solaris 10 i386
Hi, Running svnserve always results in a segmentation fault under Solaris 10 i386, even if just called with '--help'. Compile string: ./configure --prefix=/usr/local--with-apr=/usr/local/bin/apr-1-config --with-apr-util=/usr/local/bin/apu-1-config I'm using the latest UnixPackages SMCapr 1.5.2 & SMCaprutil 1.5.4 to provide the apr & apr-util libs. Workaround: Adding the ' --enable-all-static' configure flag resolves this. Steve Campbell Save Paper - Do you really need to print this e-mail? Visit www.virginmedia.com for more information, and more fun. This email and any attachments are or may be confidential and legally privileged and are sent solely for the attention of the addressee(s). Virgin Media will never ask for account or financial information via email. If you are in receipt of a suspicious email, please report to www.virginmedia.com/netreport If you have received this email in error, please delete it from your system: its use, disclosure or copying is unauthorised. Statements and opinions expressed in this email may not represent those of Virgin Media. Any representations or commitments in this email are subject to contract. Registered office: Media House, Bartley Wood Business Park, Hook, Hampshire, RG27 9UP Registered in England and Wales with number 2591237
Preserve timestamps while creating tag with SVN copy
I would like to be able to create a tag using the SVN copy command so that the timestamps on the files in the destination are the same as those in the source. Is this possible?
Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi - I have been trying to pin down the cause of an issue my users are seeing when using SVN. It's actually a Windows Server 2008 R2 (64 bit) Bitnami-Redmine stack of SVN, but I've tried to scrape it back to the most basic levels during debugging, to hopefully omit any Bitnami-related issues. I have seen this occur when the underlying SVN install is 1.8.3 and 1.8.4 I have performed the following actions (on the server itself, sing the bitnami cmd prompt to ensure all environment variables for SVN should be as expected) :: Create a new repository. No options or extras - no hooks. svnadmin create f:\svn_repository\Testrepo :: Check the empty repo out to my local disk (on the SVN Server) - obviously I've masked the real address here svn co https://xx.com/svn/Testrepo c:\dev\Testrepo :: created a simple text file manually under windows - NewDoc.txt with a few bytes of text in it so it's not empty :: Made SVN aware of the file by adding it svn add c:\dev\Testrepo\NewDoc.txt :: Committed the file into the repository svn ci c:\dev\Testrepo -m "test commit" :: Attempted to lock the working file svn lock c:\dev\Testrepo\NewDoc.txt Response: 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 I've been digging around on this for a while - seen one or two examples of people seeing this, but not seen any solutions as-of-yet. I couldn't find any trace of a bug raised either (Hopefully I've not missed one!) I've first seen this in a Bitnami 2.3.2.1 install, and to try to make sure it's not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: Same result. I have tried a totally standalone collabnet svn server install of 1.8.5 on a separate machine, and the locks on that are working. I then put 1.8.5 onto the server where we're seeing the problem and once again the same problem occurred. So this seems to be an issue occurring as a result of the configuration setup we have on that server. We do make use of an access file on that server, so my next test was to disable the access file setup and retry. This worked exactly as expected (by using a checkout using the local file system), responding that the file had been locked So, it would seem that this issue is related to the use of the following httpd.conf settings: LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule authz_svn_module modules/mod_authz_svn.s And/or serving the files over https And the related settings pointing to the relevant access authority file. Can anyone advise or assist with this? Has anyone else seen this issue? I'm starting to run out of ideas of how to further pinpoint this at the moment... Many thanks for any advice or assistance! Regards - Steve This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and agents. A division of Rapp Limited. Registered Office: 1 Riverside, Manbre Road, London W6 9WA Registered in England no: 1581935 --- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.co.uk ---
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi Bert - Firstly - is this content posting into a forum somewhere? It might be easier for me to view it there than in email each time... Answering your suggestions are easy; I am creating the repository completely manually using svnadmin create f:\svn_repository\Testrepo so, there is no part of bitnami touching this during the creation - just standard svn itself. When I look at the hooks folder for the repository, all of the items in there are the standard .tmpl (ie template) files, which as I understand it have absolutely no effect on the system; if they were modified and changed to .bat files then they would apply. So I don't see how hook files can be playing any part in this. But thanks for the feedback nonetheless; it's all helpful in ruling out what could be occurring here Kind Regards - Steve -Original Message- From: Bert Huijben [mailto:b...@qqmail.nl] Sent: 02 February 2014 15:26 To: 'Ben Reser'; Steve Davis; users@subversion.apache.org Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking > -Original Message- > From: Ben Reser [mailto:b...@reser.org] > Sent: zaterdag 1 februari 2014 02:39 > To: Steve Davis; users@subversion.apache.org > Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking > > On 1/31/14, 1:54 PM, Steve Davis wrote: > > :: Attempted to lock the working file svn lock > > c:\dev\Testrepo\NewDoc.txt > > > > Response: > > 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 > > What if anything is in the httpd error_log? > > Can you capture the network traffic between the server and the client > and post it (removing Authentication headers) for the LOCK request? > > > I've first seen this in a Bitnami 2.3.2.1 install, and to try to > > make sure it's > > not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 install: > > Same result. > > I'm not familiar with Bitnami Redmine, can you tell us what version of httpd > you have with it? > > > I have tried a totally standalone collabnet svn server install of > > 1.8.5 on a > > separate machine, and the locks on that are working. I then put > > 1.8.5 onto > the > > server where we're seeing the problem and once again the same > > problem > occurred. > > So this seems to be an issue occurring as a result of the > > configuration setup > > we have on that server. We do make use of an access file on that > > server, so > my > > next test was to disable the access file setup and retry. This > > worked exactly > > as expected (by using a checkout using the local file system), responding > that > > the file had been locked > > > > So, it would seem that this issue is related to the use of the > > following httpd.conf settings: > > LoadModule dav_svn_module modules/mod_dav_svn.so LoadModule > > authz_svn_module modules/mod_authz_svn.s And/or > > > > serving the files over https > > Doubtful. > > > And the related settings pointing to the relevant access authority file. > > This is more likely. Can you post your configuration? And can you check what repository hooks are installed into your repository by the Bitnami framework? You can get into this exact problem if you have a pre-lock script that produces some whitespace only output on stdout. The output of this hook is used as lock token. (See http://subversion.apache.org/docs/release-notes/1.6.html#hook-changes) But in this case the surrounding whitespace is filtered and an empty token is exactly what remains. Bert This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and a
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Hi Ben - To try to answer as many of the questions you raised as possible: In the httpd error_log I'm seeing this each time I attempt to lock a file and fail: [Mon Feb 03 10:58:52.092999 2014] [dav:error] [pid 2776:tid 1160] [client xx.xx.xx.xx:x] Tried to attach multiple locks to a resource. [400, #405] This has lead me off on another set of googling to try and pin this down. It would seem again that a few people have seen the same or very similar, specifically in the windows environment. But I still see no sign of a resolution forthcomng (yet) Eg: http://community.bitnami.com/t/cannot-svn-lock-files-with-bitnami-trac-1-0-1-client-400-bad-request-server-tried-to-attach-multiple-locks-to-a-resource/14779/21 Again, from the httpd error log I see the apache version details as follows: [Mon Feb 03 10:26:21.216999 2014] [mpm_winnt:notice] [pid 4932:tid 384] AH00455: Apache/2.4.7 (Win32) SVN/1.8.4 OpenSSL/0.9.8y PHP/5.4.0 configured -- resuming normal operations During further testing today, I have tried to simplify the scenario by 1) Eliminating the secure (https) connection redirection that was in place 2) Replacing the complex access file config we normally have in place with the more straightforward (I was say simple as I'm sure it's not under the covers!) AuthBasicProvider file. You have to have some sort of authentication in place otherwise the lock fails (which is logical) So, I now have a scenario which should be far more easy to recreate on another system and (hopefully) easier to debug. The process I used is as follows: 1) Install Bitnami Redmine stack 2.4.2 from https://bitnami.com/stack/redmine 2) Modify (installdir)\apache2\conf\bitnami\bitnami.conf, adding the following line at the end of the file: include "F:/BitNami/redmine-2.4.2-0/apache2/conf/bitnami/rapp.conf" (Modify the base install dir as needed) 3) Add the attached rapp.conf file into the (installdir)\apache2\conf\bitnami directory (This contains the relevant DAV access settings) 4) Add a user to the new password file htpasswd -c c:\svn_admin\passwords.txt steve 5) Restart apache using either the standard windows service or the bitnami config tool (Start /Programs / Bitnami Redmine Stack / Redmine Manager Tool) Then follow the sequence (as documented before, but using http instead of https) :: Create a new repository. No options or extras - no hooks. svnadmin create f:\svn_repository\Testrepo :: Check the empty repo out to my local disk (on the SVN Server) - obviously I've masked the real address here svn co http://xx.com/svn/Testrepo c:\dev\Testrepo :: (create a simple text file manually under windows - NewDoc.txt with a few bytes of text in it so it's not empty) :: Made SVN aware of the file by adding it svn add c:\dev\Testrepo\NewDoc.txt :: Committed the file into the repository svn ci c:\dev\Testrepo -m "test commit" :: Attempted to lock the working file svn lock c:\dev\Testrepo\NewDoc.txt Response: 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 Additional content in httpd error.log: [Mon Feb 03 12:30:13.322999 2014] [dav:error] [pid 4968:tid 1148] [client xxx.xxx.xxx.xxx:x] Tried to attach multiple locks to a resource. [400, #405] I've also attached both the httpd.conf and the bitnami.conf files to help with debugging. Pretty much everything in the conf files is 'as installed in the bitnami stack' with the only modifications made being those mentioned above - basically implementing DAV and basic security to permit the testing to be done (given that using file:/// type access does not recreate the issue). I will talk to my network people to see if we can track down the net traffic and post that too. Any further feedback very much appreciated. Thanks - Steve -Original Message- From: Ben Reser [mailto:b...@reser.org] Sent: 01 February 2014 01:39 To: Steve Davis; users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking On 1/31/14, 1:54 PM, Steve Davis wrote: > :: Attempted to lock the working file > svn lock c:\dev\Testrepo\NewDoc.txt > > Response: > 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 What if anything is in the httpd error_log? Can you capture the network traffic between the server and the client and post it (removing Authentication headers) for the LOCK request? > I've first seen this in a Bitnami 2.3.2.1 install, and to try to make > sure it's not already been fixed I just updated to a Bitnami Redmine 2.4.2.0 > install: > Same result. I'm not familiar with Bitnami Redmine, can you tell us what version of httpd you have with it? > I have tried a totally standalone c
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time? Thanks for your time on this Regards - Steve -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 03 February 2014 15:34 To: Steve Davis Cc: users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Steve Davis writes: > Response: > > 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 I can generate this error with the 1.8 client by patching mod_dav_svn to return 400: Index: sw/subversion/src/subversion/mod_dav_svn/lock.c === --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833) +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy) @@ -670,7 +670,7 @@ DAV_ERR_LOCK_SAVE_LOCK, "Path is not accessible."); - if (lock->next) + /*if (lock->next)*/ return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST, DAV_ERR_LOCK_SAVE_LOCK, "Tried to attach multiple locks to a resource."); A trunk client gives a better error: svn: warning: W160040: No lock on path 'f' (400 Bad Request) The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838 a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320 somebody else reports a similar incompatibility which was solved by using different binaries. Do you know how your Apache and Subversion binaries were produced? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and agents. A division of Rapp Limited. Registered Office: 1 Riverside, Manbre Road, London W6 9WA Registered in England no: 1581935 --- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.co.uk ---
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Ah - with a bit of digging around the binary libraries, I can see that it looks like subversion was still built using vc6, and apache using a mix of 2008 and/or 2010. This being the case, I'd say that this is a prime candidate for what's causing the problem (based upon the comments in the second link)... So it's not a problem with Redmine or with apache - but it >is< a problem when the binaries used aren't built using the same version of compiler (this is all theory at the moment of course) -Original Message- From: Steve Davis Sent: 03 February 2014 15:35 To: 'Philip Martin' Cc: users@subversion.apache.org Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking All of the Apache and Subversion binaries came from the Bitnami download. I could ask their support people exactly what compiler was used if you think that would help? Anything else I should be asking them at the same time? Thanks for your time on this Regards - Steve -Original Message- From: Philip Martin [mailto:philip.mar...@wandisco.com] Sent: 03 February 2014 15:34 To: Steve Davis Cc: users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Steve Davis writes: > Response: > > 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 I can generate this error with the 1.8 client by patching mod_dav_svn to return 400: Index: sw/subversion/src/subversion/mod_dav_svn/lock.c === --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833) +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy) @@ -670,7 +670,7 @@ DAV_ERR_LOCK_SAVE_LOCK, "Path is not accessible."); - if (lock->next) + /*if (lock->next)*/ return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST, DAV_ERR_LOCK_SAVE_LOCK, "Tried to attach multiple locks to a resource."); A trunk client gives a better error: svn: warning: W160040: No lock on path 'f' (400 Bad Request) The question remains why are you getting a 400 Bad Request from the server. As far as I am aware this has only ever been observed by people using Windows and I think it could be an incompatibility between the way Apache and Subversion are built. In this discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=894838 a patch/rebuild is reported to fix the problem but the person producing the patch realises that the patch does nothing. Therefore what solved the problem was the rebuild, not the patch. In the same discussion: http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=905320 somebody else reports a similar incompatibility which was solved by using different binaries. Do you know how your Apache and Subversion binaries were produced? -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data* This e-mail and any files transmitted with it are confidential and intended solely for the individual or entity to whom they are addressed. Any views or opinions presented or expressed are those of the author(s) and may not necessarily represent those of the business and no representation is given nor liability accepted for the accuracy or completeness of any information contained in this email unless expressly stated to the contrary. If you are not the intended recipient or have received this e-mail in error, you may not use, disseminate, forward, print or copy it, but please notify the sender that you have received it in error. Whilst we have taken reasonable precautions to ensure that any attachment to this e-mail has been swept for viruses, we cannot accept liability for any damage sustained as a result of software viruses and would advise that you carry out your own virus checks before opening any attachment. Please note that communications sent by or to any person through our computer systems may be viewed by other company personnel and agents. A division of Rapp Limited. Registered Office: 1 Riverside, Manbre Road, London W6 9WA Registered in England no: 1581935 --- This email message has been delivered safely and archived online by Mimecast. For more information please visit http://www.mimecast.co.uk ---
RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking
Great, Thanks. My expectation is that it will all work fine... until you get to file locking - which will fail. -Original Message- From: Alagazam.net Subversion [mailto:s...@alagazam.net] Sent: 03 February 2014 21:51 To: Steve Davis Cc: users@subversion.apache.org Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking Hi everyone. I got curious to see if they are using my VC6 build of Subversio a.k.a. Win32SVN. And my suspision it true, it's the Win32SVN 1.8.4 build for Apache 2.4.x that's is included in the Bitnami Redmine Windows installer. Building Win32SVN and testing is done against a httpd built at the same time (or sometimes a previous build) with the same compiler VC6. I haven't tested Win32SVN with httpd built using more modern VC++. It seems like Bitnami's httpd it built with VS2010 (at least as Dependency Walker shows). If time permit I can try to run the svn testsuite with these installation. Best regards David a.k.a. Alagazam Maintainer of Win32SVN On 2014-02-03 17:31, Steve Davis wrote: > Ah - with a bit of digging around the binary libraries, I can see that > it looks like subversion was still built using vc6, and apache using a > mix of 2008 and/or 2010. > > This being the case, I'd say that this is a prime candidate for what's > causing the problem (based upon the comments in the second link)... > > So it's not a problem with Redmine or with apache - but it >is< a > problem when the binaries used aren't built using the same version of > compiler (this is all theory at the moment of course) > > -Original Message- > From: Steve Davis > Sent: 03 February 2014 15:35 > To: 'Philip Martin' > Cc: users@subversion.apache.org <mailto:users@subversion.apache.org> > Subject: RE: Possible bug in SVN 1.8.3 and 1.8.4 - file locking > > All of the Apache and Subversion binaries came from the Bitnami > download. I could ask their support people exactly what compiler was > used if you think that would help? Anything else I should be asking > them at the same time? > > Thanks for your time on this > > Regards - Steve > > -Original Message- > From: Philip Martin [mailto:philip.mar...@wandisco.com] > Sent: 03 February 2014 15:34 > To: Steve Davis > Cc: users@subversion.apache.org <mailto:users@subversion.apache.org> > Subject: Re: Possible bug in SVN 1.8.3 and 1.8.4 - file locking > > Steve Davis <mailto:steve.da...@uk.rapp.com>> > writes: > > > Response: > > > > 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 > > I can generate this error with the 1.8 client by patching mod_dav_svn > to return 400: > > Index: sw/subversion/src/subversion/mod_dav_svn/lock.c > === > --- sw/subversion/src/subversion/mod_dav_svn/lock.c (revision 1563833) > +++ sw/subversion/src/subversion/mod_dav_svn/lock.c (working copy) > @@ -670,7 +670,7 @@ > DAV_ERR_LOCK_SAVE_LOCK, > "Path is not accessible."); > > - if (lock->next) > + /*if (lock->next)*/ > return dav_svn__new_error(resource->pool, HTTP_BAD_REQUEST, > DAV_ERR_LOCK_SAVE_LOCK, "Tried to attach multiple locks to a > resource."); > > A trunk client gives a better error: > > svn: warning: W160040: No lock on path 'f' (400 Bad Request) > > The question remains why are you getting a 400 Bad Request from the > server. As far as I am aware this has only ever been observed by > people using Windows and I think it could be an incompatibility > between the way Apache and Subversion are built. In this discussion: > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessag > eId=894838 > > > a patch/rebuild is reported to fix the problem but the person > producing the patch realises that the patch does nothing. Therefore > what solved the problem was the rebuild, not the patch. In the same > discussion: > > http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessag > eId=905320 > > > somebody else reports a similar incompatibility which was solved by > using different binaries. > > Do you know how your Apache and Subversion binaries were produced? > > -- > Philip Martin | Subversion Committer > WANdisco // *Non-Stop Data* > > > This e-mail and any files transmitted with it are confidential and > intended solely for the individual or entity to whom they are addressed. > Any views or opinions presented or expressed are those of the > author(s) and may not necessarily represent those of the busine
Path-based authentication with 1.8.8
Hello, I have been experiencing a problem using path-based authorization with version 1.8.8 and Apache. I am attempting to give a couple of users RW access to a particular sub-directory but when they attempt to commit changes they are denied. Here is a snippet of the authorization file. [groups] @users = User1, User2, User3 [repo:/Projects] @users = rw User4 = r User5 = r [repo:/Projects/Software/Client] User4 = rw User5 = rw The problem is User4 and User5 cannot commit changes to files in [repo:/Projects/Software/Client]. The documentation indicates that this configuration should allow such commits. If I add User4 = rw and User5 = rw to [repo:/Projects] the users are able to successfully commit. Has anyone seen this issue? I am fairly certain we have not encountered such problems with past versions. --- Steve Boone, P.Eng. IO Industries Inc. +1 519 663 9570
Re: Path-based authentication with 1.8.8
Sorry, I edited my file before I posted to remove company sensitive info. The actual file is ... [groups] users = User1, User2, User3 -Original Message- From: Philip Martin Sent: Monday, March 10, 2014 3:10 PM To: Steve Boone Cc: users@subversion.apache.org Subject: Re: Path-based authentication with 1.8.8 Steve Boone writes: [groups] @users = User1, User2, User3 @ here is wrong. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Re: Path-based authentication with 1.8.8
Here are the messages from the error log ... [Mon Mar 10 15:46:58.952850 2014] [authz_svn:error] [pid 1328:tid 748] [client 192.168.0.24:51106] Access denied: 'StevenH' PUT iosource:/DVRY/Software/trunk/user_guides/video_server/graphics/video_server_config_general_settings_3.png [Mon Mar 10 15:48:05.317044 2014] [authz_svn:error] [pid 1328:tid 748] [client 192.168.0.24:51109] Access denied: 'StevenH' PUT iosource:/DVRY/Software/trunk/user_guides/video_server/appendix.html In the authorization file ... The user StevenH has read access to the folder iosource:/DVRY/ [iosource:/DVRY] @dvry = rw StevenH = r AND read/write access to iosource:/DVRY/Software/trunk/user_guides/video_server [iosource:/DVRY/Software/user_guides/video_server] StevenH = rw -Original Message- From: Philip Martin Sent: Monday, March 10, 2014 4:24 PM To: Steve Boone Cc: users@subversion.apache.org Subject: Re: Path-based authentication with 1.8.8 Steve Boone writes: Sorry, I edited my file before I posted to remove company sensitive info. The actual file is ... [groups] users = User1, User2, User3 -Original Message- From: Philip Martin Sent: Monday, March 10, 2014 3:10 PM To: Steve Boone Cc: users@subversion.apache.org Subject: Re: Path-based authentication with 1.8.8 Steve Boone writes: [groups] @users = User1, User2, User3 @ here is wrong. It would help if you provided the error messages, both from the client and in the server log. -- Philip Martin | Subversion Committer WANdisco // *Non-Stop Data*
Subversion for IBM i (OS/400)
Hi, I am not a current subscriber to this mailing list and would appreciate being explicitly CC:ed in any responses. I currently use Subversion for IBM i (OS/400) which runs on IBM i (OS/400) version V7R1. This was originally an open source project from SoftLanding Systems. Is Subversion no longer being maintained/developed for IBM i (OS/400) now that it is under Apache? The reason I ask is I don't see OS/400 listed in the Apache Subversion Binary Packages list (http://subversion.apache.org/packages.html). Thanks in advance for any information on this. Thanks, Steve [http://www.yardi.com/images/yardi_logo_small.gif] Steve Coffey | Programmer, CTI toll free 800-390-7625 | local 972-419-4872 | fax 972-763-0700 Yardi Systems, Inc. | 14785 Preston Road, Suite 250 | Dallas, TX 75254 steve.cof...@yardi.com<mailto:steve.cof...@yardi.com> | www.yardi.com<http://www.yardi.com> NOTICE: This email message, including any attachments, may contain information that is confidential and/or proprietary. If you are not an intended recipient, please be advised that any review, use, reproduction or distribution of this message is prohibited. If you have received this message in error, please completely destroy all electronic and hard copies, and contact the sender at toll free 800-390-7625 or steve.cof...@yardi.com<mailto:steve.cof...@yardi.com>.
Svn externals question
Hi, Currently we are attempting to use svn externals to help build various projects from what I would call a few "reuse" repositories. We are attempting to be "structured" as to what level of design hierarchy we apply the properties but sometimes when we inherit a design people can spend a bit of time trying to identify where externals have been used. Is there a simple way of identifying in a structure folders that have external properties, come to think of it maybe any form of property ? Thanks for any help. Regards Steve Hutchinson FPGA Group Leader This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Svn externals question
Hi, Was looking to answer point 1 below not 2. Guess I should have RTFM a bit more on that one... but thanks all for the help. So that helps nicely with how to identify where all the properties are. >From reading all the answers I got have some questions on the best use of svn:externals. Will use another answer to continue that thread. Regards Steve H -Original Message- From: David Weintraub [mailto:qazw...@gmail.com] Sent: 05 November 2010 16:17 To: Hutchinson, Steve (UK) Cc: users@subversion.apache.org Subject: Re: Svn externals question >>>>> SPECIAL MBDA ALERT - SECURITY INCREASED PLEASE TAKE EXTRA CARE NOT TO CLICK ON HYPERLINKS WHERE YOU DO NOT KNOW THE SENDER ANY SUSPICIOUS EMAIL, PLEASE FORWARD TO ftn.VIRUS CONTROL <<<<< *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. On Fri, Nov 5, 2010 at 9:49 AM, Hutchinson, Steve (UK) wrote: > Is there a simple way of identifying in a structure folders that have > external properties, come to think of it maybe any form of property ? Not 100% clear what you're looking for. You could be looking for one of two things: 1). You have a project, and it has svn:externals set on certain folders. You want to find those folders. That's fairly easy to do with the "svn propget". Go to the root of your project and run: $ svn propget -v -R svn:externals That will show you all the directories where svn:externals are set and directories are being pulled in. 2). You have a bunch of "external" projects, and want to know in what other projects they're being used. This is much more difficult since there's no way to see what projects are using a particular directory as an external project. The only thing I can think of is to run the "svn propget" on the entire repository and parse the output. -- David Weintraub qazw...@gmail.com This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Svn externals question
Hi >The designers of the externals feature envisioned maybe a handful of external library dependencies that don't vary much over time. >These are automatically pulled into a working copy, much like an automated svn checkout. >But the design doesn't account for what happens when people start using svn:externals for variant management or large-scale component reuse. >If you're pulling together project components from externals in various combinations, like lego blocks, or simply have many externals, don't use the svn:externals properties as the primary source of your configuration data. Yes, currently I am pulling together project components from externals... like lego blocks. I think in nearly all situations we are referencing a specific revision of the external directory structure in the project external properties. The vast majority of the time the external data is actually within the same repository, but there are a few situations where it is in another repo. >Do it the other way: Store your component configuration in a versioned file or even a database, and write a script to configure svn:externals properties based on that data. Maybe even add an automated check into the mix that makes sure the svn:externals in the repository's HEAD revision >are in sync with your primary externals configuration source. I think unfortunately this is where you lose me :) I am not too sure why this is too different from "the other way". In both situations I end up with a set of project folders with svn:externals on them. but the latter I say have one top level "externals.lst" and associated script file that is used to apply them. Probably a reflection of my knowledge level but not clear where the gain has come from ? >Hope this helps, >Stefan This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Svn externals question
Stefan, Your point well understood now. Thanks for the clarification, appreciated. Steve H -Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: 08 November 2010 17:01 To: Hutchinson, Steve (UK) Cc: users@subversion.apache.org Subject: Re: Svn externals question >>>>> SPECIAL MBDA ALERT - SECURITY INCREASED FOR WEEK COMMENCING >>>>> 08/11/10 PLEASE TAKE EXTRA CARE NOT TO CLICK ON HYPERLINKS WHERE YOU DO NOT KNOW THE SENDER ANY SUSPICIOUS EMAIL, PLEASE FORWARD TO ftn.VIRUS CONTROL <<<<< *** WARNING *** This mail has originated outside your organization, either from an external partner or the Global Internet. Keep this in mind if you answer this message. On Mon, Nov 08, 2010 at 10:24:03AM -, Hutchinson, Steve (UK) wrote: > >Do it the other way: Store your component configuration in a > >versioned file or even a database, and write a script to configure > >svn:externals properties based on that data. Maybe even add an > >automated check into the mix that makes sure the svn:externals in the > >repository's HEAD revision >are in sync with your primary externals configuration source. > > I think unfortunately this is where you lose me :) I am not too sure > why this is too different from "the other way". In both situations I > end up with a set of project folders with svn:externals on them. > but the latter I say have one top level "externals.lst" and associated > script file that is used to apply them. Probably a reflection of my > knowledge level but not clear where the gain has come from ? It depends on what you need to do with information about your modules. It also depends on scale. If svn propget -R output is sufficient and fast enough for you, then you don't need a separate database of externals information. In this case you simply haven't scaled up your usage of externals to the point where propget -R becomes inhibiting. E.g. if you need tool support to configure and compose your modules or variants because you have a lot of them (say, various kinds of embedded devices built from common parts), having the configuration data in svn properties means that an application has to crawl the repository to figure out which components are used where. Also consider that you need might to crawl more than one revision to find an answer you're looking for. A database can instantly tell you things like "this component is no longer used, and was last used in devices A, B and C." if fed a proper query. If such information is hidden in externals in past revisions, you're putting unnecessary load on your Subversion server by trying to track down the right properties. Stefan This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
SVN Externals query
Hi group, We have a product development structure that looks a bit like below :- trunk Design Module_A file_bundle_x_source Module_B file_bundle_y_source Verification - (externals) Simulation_1 file_bundle_x Simulation_2 file_bundle_x Simulation_3 file_bundle_y file_bundle_x Basically some source files are generated within the Design folder under their respective modules. These source files need to be used within the test environment. One option would have been to "script" the copying of the various bundles to the appropriate simulation environment when they change. There is scope for these bundles to become large so I thought that using svn:externals on my verification folder seemed like a good idea. The properties taking the form a bit like below. -r777 https \trunk\Design\Module_A\file_bundle_x_source Simulation_1/file_bundle_x Generally speaking from a trunk perspective everything seemed ok. then we branch to investigate a problem. Due to probably inexperience we now have a branch that is not really self contained? Modifications on the branch can directly impact the trunk, well on the externals bit anyway. One thought is to have the externals property be relative to the parent folder, which I think would then prevent the branch direct link to the trunk. We were very keen to ensure that any externals property refers to a specific revision (or my tags not self contained) but I do not appear to be able to link a specific revision and use relative paths? Any other better ideas ? Regards Steve Hutchinson FPGA Group Leader This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
Dangerous to keep re-integrated branches alive?
Hi all, My development group uses quite a bit of branching. I'm trying to train folks to delete a task branch once it is integrated and create a new one for the next task. Of course the svnbook gives the recipe for "Keeping a reintegrated branch alive", by using a record-only merge to block the integrated revision from being merged back to the task branch later on. (when sync-ing up the branch) It has always seemed to me that that is risky. If there were changes in the re-integration merge for conflict resolution, etc, then those changes are also being blocked from being merged back to the (kept-alive) task branch. Future changes on the task branch don't include those fixes and future re-integrations could potentially even over-write them (since the mergeinfo data says we're all up-to-date with respect to that prior revision). I hope that description is not too abstract. Am I worrying about a non-existent problem, or is there really potential to drop a change that should have gotten merged forward? I know we can always go back in history and find the change, but I'd rather set up our branch/merge process to be as correct as possible and not rely on testing to find that we dropped bit of code. TIA, -Steve
RE: Dangerous to keep re-integrated branches alive?
-Original Message- From: Stefan Sperling [mailto:s...@elego.de] Sent: Saturday, February 12, 2011 5:10 AM To: Daniel Becroft Cc: Varnau, Steve (Neoview); users@subversion.apache.org Subject: Re: Dangerous to keep re-integrated branches alive? On Sat, Feb 12, 2011 at 04:08:26PM +1000, Daniel Becroft wrote: > On Sat, Feb 12, 2011 at 1:10 PM, Varnau, Steve (Neoview) < > steve.var...@hp.com> wrote: > > > Hi all, > > > > My development group uses quite a bit of branching. I’m trying to train > > folks to delete a task branch once it is integrated and create a new one for > > the next task. Of course the svnbook gives the recipe for “Keeping a > > reintegrated branch alive”, by using a record-only merge to block the > > integrated revision from being merged back to the task branch later on. > > (when sync-ing up the branch) > > > > It has always seemed to me that that is risky. If there were changes in the > > re-integration merge for conflict resolution, etc, then those changes are > > also being blocked from being merged back to the (kept-alive) task branch. > > Future changes on the task branch don’t include those fixes and future > > re-integrations could potentially even over-write them (since the mergeinfo > > data says we’re all up-to-date with respect to that prior revision). I would say that depends on the kind of conflict resolution. Maybe you're resolving a conflict in a way that is specific to trunk and must never go to the branch (i.e. you will keep the conflicting piece of code for a while and resolve it later). In that case, it's correct that the revision is blocked from being merged into the branch. Else, you should require that the reintegrate merge is conflict-free. So if you run into the situation where another commit to trunk sneaks in after you sync but before you reintegrate, you simply sync again and then try to reintegrate again. > > My understanding is that this should never happen. During a reintegration > merge, there is validation that all revisions from the target (normally > /trunk) have been merged across into the branch - any conflict resolution is > done during this merge. The reintegration merge then does a basic file > compare, and merges across. It can happen if someone commits to trunk after you sync the branch to trunk but before you reintegrate it. > After the reintegration merge, /trunk and the branch should be bit-by-bit > identical. Period. No. That's not true in the general case. It's a common misunderstanding though. See here for details: http://mail-archives.apache.org/mod_mbox/subversion-users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E -- Thanks for both replies. So, at least one could do a double-check if the files involved in the re-integration check-in revision are identical on the branch. They should be, and if so, then it is safe to block the merge and keep the branch alive. -Steve
RE: Dangerous to keep re-integrated branches alive?
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Monday, February 14, 2011 9:54 AM > To: Varnau, Steve (Neoview) > Cc: Daniel Becroft; users@subversion.apache.org > Subject: Re: Dangerous to keep re-integrated branches alive? > > On Mon, Feb 14, 2011 at 05:41:03PM +, Varnau, Steve (Neoview) > wrote: > > > > > > -Original Message- > > From: Stefan Sperling > > Sent: Saturday, February 12, 2011 5:10 AM > > To: Daniel Becroft > > Cc: Varnau, Steve (Neoview); users@subversion.apache.org > > > Subject: Re: Dangerous to keep re-integrated branches alive? > > > After the reintegration merge, /trunk and the branch should be bit- > by-bit > > > identical. Period. > > > > No. That's not true in the general case. It's a common > misunderstanding though. > > See here for details: http://mail- > archives.apache.org/mod_mbox/subversion- > users/201009.mbox/%3c20100929200923.gc7...@ted.stsp.name%3E > > > > -- > > Thanks for both replies. So, at least one could do a double-check if > the files involved in the re-integration check-in revision are > identical on the branch. They should be, and if so, then it is safe to > block the merge and keep the branch alive. > > > > -Steve > > No, the files can differ. E.g. consider what happens if the branch modifies > the very last line of a file. Now the branch is synced to trunk to prepare > it for reintegration. The file receives no changes. Next, someone commits > a change to trunk changing the very first line of the file. Then you > perform the reintegrate merge, and it's likely that this merge is > conflict-free (unless the file is very short). Now you commit the result > of the reintegration merge, and the files on the branch and the trunk are > not the same -- they differ in the first line. Okay, but then I would not want to block that revision with a record-only merge, right? I would want to pick up that merge resolution the next time I sync-up the branch. -Steve
RE: Dangerous to keep re-integrated branches alive?
> -Original Message- > From: Stefan Sperling [mailto:s...@elego.de] > Sent: Monday, February 14, 2011 11:27 AM > To: Varnau, Steve (Neoview) > Cc: Daniel Becroft; users@subversion.apache.org > Subject: Re: Dangerous to keep re-integrated branches alive? > > On Mon, Feb 14, 2011 at 06:05:26PM +, Varnau, Steve (Neoview) > wrote: > > > -Original Message- > > > From: Stefan Sperling > > > No, the files can differ. E.g. consider what happens if the branch > modifies > > > the very last line of a file. Now the branch is synced to trunk to > prepare > > > it for reintegration. The file receives no changes. Next, someone > commits > > > a change to trunk changing the very first line of the file. Then > you > > > perform the reintegrate merge, and it's likely that this merge is > > > conflict-free (unless the file is very short). Now you commit the > result > > > of the reintegration merge, and the files on the branch and the > trunk are > > > not the same -- they differ in the first line. > > > > Okay, but then I would not want to block that revision with a record- > only merge, right? I would want to pick up that merge resolution the > next time I sync-up the branch. > > > > Which revision do you intend to block, precisely? > > I think you eventually want to merge into the branch the revision that > added the first line to the file on trunk. > But that is not the same revision as the one that committed the result > of the reintegrate merge. So in this example it's perfectly fine to > block > the reintegration revision from being merged into the branch, isn't it? Ah, quite right. Then the harder case is if the intervening change to trunk also changed the last line. Then my reintegration merge has to do conflict resolution. Perhaps some combination of the changes on that last line. I commit that to trunk, and block my latest trunk revision from being merged back to my branch. So, the next time I do synch up the branch, I get to resolve that same conflict again on the branch, hopefully the same or better resolution as on trunk. That seems fine. As long as I did not get fancy and make other gratuitous changes that were not strictly conflict resolution in the reintegration merge, it should be okay to keep the branch alive. Thanks for helping me think that through. -Steve
Merge Conflict on Windows with eol-style & mergeinfo properties
Hi, I could not find this issue in the issue tracker. We're trying to keep the svn:mergeinfo properties on top-level directories, but I found a few text files in our repository that have the property. When a merge is done that should be just a branch synch-up merge, the files are marked as conflicted, and the entire file is one big conflict, as if it is an EOL character problem. All of the files that are marked as conflicted have in common two properties. They have an svn:mergeinfo, and they have svn:eol-style = native. Both branches have the same svn:eol-style value. The text file that did not have an svn:eol-style property merged just fine. When the files are edited (Tortoise "Edit conflicts") it shows no conflicts -- merge with no problem. Looking at the files, there are no EOL character differences. Both sides (left & right files, and both sides of the working conflict file) have CRLF. The files also merge fine on Linux. The files also merge fine if given the option to ignore end-of-line. The problem occurs whether the merge is done via Tortoise or command-line on Windows. Svn version 1.6.15. Somehow it seems to be giving up merging these files only when there is a svn:mergeinfo property. I will try to just remove the mergeinfo property on all the files, but wondered if this is a general bug. -Steve
RE: Merge Conflict on Windows with eol-style & mergeinfo properties
> -Original Message- > From: Johan Corveleyn [mailto:jcor...@gmail.com] > Sent: Thursday, February 24, 2011 1:47 AM > To: Varnau, Steve (Neoview) > Cc: users@subversion.apache.org > Subject: Re: Merge Conflict on Windows with eol-style & mergeinfo > properties > > On Thu, Feb 24, 2011 at 12:56 AM, Varnau, Steve (Neoview) > wrote: > > Hi, > > > > I could not find this issue in the issue tracker. We're trying to > keep the > > svn:mergeinfo properties on top-level directories, but I found a few > text > > files in our repository that have the property. When a merge is done > that > > should be just a branch synch-up merge, the files are marked as > conflicted, > > and the entire file is one big conflict, as if it is an EOL character > > problem. > > > > All of the files that are marked as conflicted have in common two > > properties. They have an svn:mergeinfo, and they have svn:eol-style = > > native. Both branches have the same svn:eol-style value. The text > file that > > did not have an svn:eol-style property merged just fine. > > > > When the files are edited (Tortoise "Edit conflicts") it shows no > conflicts > > -- merge with no problem. Looking at the files, there are no EOL > character > > differences. Both sides (left & right files, and both sides of the > working > > conflict file) have CRLF. > > > > The files also merge fine on Linux. > > The files also merge fine if given the option to ignore end-of-line. > > The problem occurs whether the merge is done via Tortoise or command- > line on > > Windows. > > Svn version 1.6.15. > > > > Somehow it seems to be giving up merging these files only when there > is a > > svn:mergeinfo property. > > > > I will try to just remove the mergeinfo property on all the files, > but > > wondered if this is a general bug. > > I think this is the following issue: > > http://subversion.tigris.org/issues/show_bug.cgi?id=3657 - dav update > report handler in skelta mode can cause spurious conflicts > > (this issue previously had another summary: "phantom svn:eol-style > changes cause spurious merge text conflicts", which may sound more > recognizable, but this was later changed when they found out more > about the issue). > > It describes more or less the same situation: a merge with some prop > change which happens together with a text change, and the entire file > is marked as conflicted. I've run into this situation myself a couple > of times (I then just resolved the conflict by choosing "theirs-full" > or something, after having assured myself that this was indeed the > issue). > > It's fixed in svn trunk, so scheduled to be in the upcoming 1.7 > release. AFAIK, it's not currently nominated for backport to 1.6. > > Cheers, > -- > Johan Yes, that does appear to be the one! Thank you. -Steve
Merge tracking bug - inherited merge-range
Greetings, I have a merge tracking bug to report. It seems like there are a lot of steps to re-produce it, but we discovered this in the real world, and it took a long while to figure out what was going on and to re-produce it. We are running 1.6.15 clients. We have lots of branching, and unfortunately svn:mergeinfo at multiple levels. This bug apparently only shows up if you merge two levels of directory that have new mergeinfo properties. The lower level directory does not get updated correctly and causes duplicate merge conflicts later. Yes, I know "best practice" says to merge only at the top-level, but in a large project, those merge-tracking properties can grow like weeds. The example steps below to reproduce use multiple branches just to produce the mergeinfo at multiple directory levels. There might be a simpler way to reproduce it. I did not find anything in the issue tracker, and I have not tried this with 1.6.16 or with pre-release 1.7. -Steve # create sub-directory tree $ svn co file:///c:/temp/svn-test/trunk trunk-wc $ cd trunk-wc/ $ svn mkdir subA $ svn mkdir subA/subB $ svn ci -m "need 2 directories" $ svn cp ^/trunk ^/branch/br1 # first branch adds some content $ cd .. $ svn co file:///c:/temp/svn-test/branch/br1 br1-wc $ cd br1-wc/subA $ touch foo $ touch subB/bar $ svn add foo subB/bar $ svn ci -m "br1 adds" # second project branch picks up the directories before project 1 delivers # third and forth start later $ cd ../.. $ cd trunk-wc/ $ svn cp ^/trunk ^/branch/br2 -m "victim project" $ svn merge --reintegrate ^/branch/br1 $ svn ci -m "" $ svn cp ^/trunk ^/branch/br3 -m "foo project" $ svn cp ^/trunk ^/branch/br4 -m "bar project" # three projects working concurrently, project 3 & 4 make changes $ cd .. $ svn co file:///c:/temp/svn-test/branch/br2 br2-wc $ svn co file:///c:/temp/svn-test/branch/br3 br3-wc $ svn co file:///c:/temp/svn-test/branch/br4 br4-wc $ cd br3-wc/subA/ $ echo "change" > foo $ svn ci -m "" $ cd ../../br4-wc/subA/subB/ $ echo "change" > bar $ svn ci -m "" # project 2 first synchs up the changes from br1 $ cd ../../../br2-wc/ $ svn merge ^/trunk $ svn ci -m "synch 1" $ svn up At revision 88. # project 3 & 4 each deliver content AND incidentally add svn:merginfo properties to subA & subB $ cd ../trunk-wc/subA/subB/ $ svn up $ svn merge --reintegrate ^/branch/br4/subA/subB $ svn ci -m "deliver bar" Committed revision 89. $ cd .. $ svn up $ svn merge --reintegrate ^/branch/br3/subA $ svn ci -m "deliver foo" Committed revision 90. # project 2 synchs up again, including svn:mergeinfo $ cd ../../br2-wc/ $ svn merge ^/trunk --- Merging r88 through r90 into '.': UsubA\foo UsubA\subB\bar U subA\subB U subA # at this point mergeinfo is correct for subA, but not for subB # The content looks okay, so we check in and try another synch merge # Even though nothing changed on trunk, we get duplicate merge conflict $ svn ci -m "synch 2" $ svn up At revision 91. $ svn merge ^/trunk --- Merging r82 through r87 into 'subA\subB': C subA\subB\bar Summary of conflicts: Tree conflicts: 1
RE: SVN question
Christopher,
The problem is not with your perl code. Apparently, update returns success if
you give it a path that does not exist in the current working directory.
Ø svn update foobar
At revision 3158.
Ø echo $?
0
For Svn 1.6.15, anyway. Seems to hold for linux & windows.
-Steve
From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 11:34 AM
To: users@subversion.apache.org
Subject: SVN question
Hello,
I have been wondering how best to capture errors from
the SVN command line.
I wanted to show you how a basic test is failing.
Consider the simple code snippet:
==
use strict;
my $options=" --username builduser --password ";
chdir("C:\\source");
my $output = `svn update --depth=infinity mang $options`;
die "svn failed with errorcode $?" if $?;
print "We survived!\n";
==
This command works if the "mang" above is changed to "main"
(which does exist at c:\source).
However, both code have this result:
==
C:\source\cm\script>perl svntest.pl
We survived!
C:\source\cm\script>perl svntest.pl
We survived!
==
What am I doing wrong?
Chris
[cid:image001.png@01CAF080.AD65F1E0]
Christopher Hahn
The Dude
Software Production Engineering
R&D Services, Hewlett-Packard
Phone: 858-655-4096
Cell: 619-630-9791
ch...@hp.com<mailto:christopher.h...@hp.com>
Visit our SPE Portal<http://teams5.sharepoint.hp.com/teams/SPE/default.aspx>
<>
RE: SVN question
svn does not always return success. For instance:
> svn ls
svn: '.' is not a working copy
> echo $?
1
I think this is the more normal mode that I script against. I'm not sure why
the update sub-command is so forgiving.
-Steve
From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 1:54 PM
To: Varnau, Steve (Neoview); users@subversion.apache.org
Subject: RE: SVN question
Steve,
Thank you for taking the time.
I also saw thisI was wondering what users do to get something similar
working.
The same thing happens under Perforce. The command "p4" always returns a
successful exit code. The way around that is the odd "-s" switch which causes
the
tool to emit a string like "exit: #" where the underlying commands success or
failure
was specified. Is there perhaps some similar technique for SVN?
I checked the svn Global Options and did not see anything similar.
I suppose that I can just use a pipe and watch for strings that I expect.
Take care,
Christopher
From: Varnau, Steve (Neoview)
Sent: Monday, May 23, 2011 1:33 PM
To: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
Subject: RE: SVN question
Christopher,
The problem is not with your perl code. Apparently, update returns success if
you give it a path that does not exist in the current working directory.
Ø svn update foobar
At revision 3158.
Ø echo $?
0
For Svn 1.6.15, anyway. Seems to hold for linux & windows.
-Steve
From: Hahn, Christopher (SAN DIEGO)
Sent: Monday, May 23, 2011 11:34 AM
To: users@subversion.apache.org
Subject: SVN question
Hello,
I have been wondering how best to capture errors from
the SVN command line.
I wanted to show you how a basic test is failing.
Consider the simple code snippet:
==
use strict;
my $options=" --username builduser --password ";
chdir("C:\\source");
my $output = `svn update --depth=infinity mang $options`;
die "svn failed with errorcode $?" if $?;
print "We survived!\n";
==
This command works if the "mang" above is changed to "main"
(which does exist at c:\source).
However, both code have this result:
==
C:\source\cm\script>perl svntest.pl
We survived!
C:\source\cm\script>perl svntest.pl
We survived!
==
What am I doing wrong?
Chris
[cid:image001.png@01CAF080.AD65F1E0]
Christopher Hahn
The Dude
Software Production Engineering
R&D Services, Hewlett-Packard
Phone: 858-655-4096
Cell: 619-630-9791
ch...@hp.com<mailto:christopher.h...@hp.com>
Visit our SPE Portal<http://teams5.sharepoint.hp.com/teams/SPE/default.aspx>
<>
RE: SVN question
> -Original Message-
> From: Daniel Shahaf [mailto:d...@daniel.shahaf.name]
> Sent: Monday, May 23, 2011 2:37 PM
> To: Varnau, Steve (Neoview)
> Cc: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
> Subject: Re: SVN question
>
> 'svn up nonexistent' will pull in a file (inappropriately) called
> 'nonexistent' that has been created on the server in a revision newer
> than the BASE revision of the working copy.
Quite true, but update does not complain whether or not it finds such a file.
That seems a bit surprising.
It also does not give an error if the current directory is not a working copy,
and it can't figure out where to update from:
> svn update foobar
Skipped 'foobar'
Okay, at least it gives a message, but not returning error, seems... surprising.
-Steve
>
> Varnau, Steve (Neoview) wrote on Mon, May 23, 2011 at 21:30:26 +:
> > svn does not always return success. For instance:
> >
> > > svn ls
> > svn: '.' is not a working copy
> > > echo $?
> > 1
> >
> > I think this is the more normal mode that I script against. I'm not
> sure why the update sub-command is so forgiving.
> >
> > -Steve
> >
> > From: Hahn, Christopher (SAN DIEGO)
> > Sent: Monday, May 23, 2011 1:54 PM
> > To: Varnau, Steve (Neoview); users@subversion.apache.org
> > Subject: RE: SVN question
> >
> > Steve,
> >
> > Thank you for taking the time.
> >
> > I also saw thisI was wondering what users do to get something
> similar working.
> >
> > The same thing happens under Perforce. The command "p4" always
> returns a
> > successful exit code. The way around that is the odd "-s" switch
> which causes the
> > tool to emit a string like "exit: #" where the underlying commands
> success or failure
> > was specified. Is there perhaps some similar technique for SVN?
> >
> > I checked the svn Global Options and did not see anything similar.
> >
> > I suppose that I can just use a pipe and watch for strings that I
> expect.
> >
> > Take care,
> >
> > Christopher
> >
> > From: Varnau, Steve (Neoview)
> > Sent: Monday, May 23, 2011 1:33 PM
> > To: Hahn, Christopher (SAN DIEGO); users@subversion.apache.org
> > Subject: RE: SVN question
> >
> > Christopher,
> >
> > The problem is not with your perl code. Apparently, update returns
> success if you give it a path that does not exist in the current working
> directory.
> >
> >
> > Ø svn update foobar
> >
> > At revision 3158.
> >
> > Ø echo $?
> >
> > 0
> >
> > For Svn 1.6.15, anyway. Seems to hold for linux & windows.
> >
> > -Steve
> >
> > From: Hahn, Christopher (SAN DIEGO)
> > Sent: Monday, May 23, 2011 11:34 AM
> > To: users@subversion.apache.org
> > Subject: SVN question
> >
> > Hello,
> >
> > I have been wondering how best to capture errors from
> > the SVN command line.
> >
> > I wanted to show you how a basic test is failing.
> >
> > Consider the simple code snippet:
> > ==
> > use strict;
> > my $options=" --username builduser --password ";
> >
> > chdir("C:\\source");
> > my $output = `svn update --depth=infinity mang $options`;
> >
> > die "svn failed with errorcode $?" if $?;
> > print "We survived!\n";
> > ==
> >
> > This command works if the "mang" above is changed to "main"
> > (which does exist at c:\source).
> >
> > However, both code have this result:
> > ==
> > C:\source\cm\script>perl svntest.pl
> > We survived!
> >
> > C:\source\cm\script>perl svntest.pl
> > We survived!
> > ==
> >
> > What am I doing wrong?
> >
> > Chris
> >
> >
> >
> > [cid:image001.png@01CAF080.AD65F1E0]
> >
> > Christopher Hahn
> > The Dude
> > Software Production Engineering
> > R&D Services, Hewlett-Packard
> > Phone: 858-655-4096
> > Cell: 619-630-9791
> > ch...@hp.com<mailto:christopher.h...@hp.com>
> >
> > Visit our SPE
> Portal<http://teams5.sharepoint.hp.com/teams/SPE/default.aspx>
> >
> >
> >
> >
> >
>
RE: Possible bug: --stop-on-copy stops too early
> -Original Message- > From: Dirk Heinrichs [mailto:dirk.heinri...@capgemini.com] > Sent: Tuesday, May 24, 2011 3:31 AM > To: users@subversion.apache.org > Subject: Re: Possible bug: --stop-on-copy stops too early > > Am Dienstag, 24. Mai 2011, 12:22:44 schrieb Stephen Butler: > > > The "A", along with the "from :", means that /software was > > copied from /PALISNC in this revision, so 'svn log --stop-on-copy' > > stops at this revision. > > > > I searched for "--stop-on-copy" in the bug tracker, and turned up > > > > http://subversion.tigris.org/issues/show_bug.cgi?id=2518 > > "Allow --stop-on-copy to traverse a fixed number of copies > 1" > > > > Unfortunately no one's picked it up yet. There's an interesting > > suggestion in the comments: the log shouldn't stop if the copy-source > > was deleted in the same revision. Of course, that assumes that the > > delete and the copy (the two halves of the renaming) were committed in > the same revision. > > Hmm, if it stops on _any_ copy, then maybe "svn log --stop-on-copy" is > the wrong command for finding the base rev of a branch. Is there a > better alternative? I find it is better for this use case to log from past forward to find this info. This is my trusty command to find a branch point: svn log -qv -r0:HEAD -l1 --stop-on-copy -Steve > > Bye... > > Dirk > -- > Dirk Heinrichs | Tel: +49 (0)211 56623 316 > Configuration Manager | Fax: +49 (0)211 56623 450 > Capgemini Deutschland | Mail: dirk.heinri...@capgemini.com > Wanheimerstraße 68 | Web: http://www.de.capgemini.com > D-40468 Düsseldorf | ICQ#: 110037733 > GPG Public Key C2E467BB | Keyserver: wwwkeys.pgp.net
RE: Subversion 1.6 on Ubuntu Server 11.x
From: Geoff Hoffman [mailto:ghoff...@cardinalpath.com] Sent: Friday, June 10, 2011 3:26 PM To: users@subversion.apache.org Subject: Subversion 1.6 on Ubuntu Server 11.x I posted about this on the Ubuntu forums but thus far nobody has replied. When SSH'd into the box and using svn operations, I'm getting the dastardly warning about my password is going to get stored to disk unencrypted. I read about Subversion 1.6 security changes<http://blogs.collab.net/subversion/2009/07/subversion-16-security-improvements/>. I read about Subversion 1.6 on Ubuntu Server over at superuser.com<http://superuser.com/questions/186575/whats-the-best-way-to-store-an-encrypted-svn-password-on-ubuntu-server>. I read about gnome-keyring over at stackoverflow<http://stackoverflow.com/questions/3824513/svn-encrypted-password-store>. I've been doing a lot of reading on it. I have done the following: * installed gnome-keyring *edited my ~/.subversion/config to turn password-stores = gnome-keyring edited my ~/.subversion/servers to store-passwords = yes store-plaintext-passwords = no Thing is, I'm not using any GUI so it's still not working. Should I try encfs ? I read another post about a tool from CollabNet called keyring_tool but I don't have it on this system. Where do I get that? I've never run into these issues before (new distro, new svn version). Any additional insight would be very much appreciated. You also have to run the gnome-keyring-daemon. Most of the docs assume you do it from a GUI, but you don't have to. Just set up some shell login script to start one (per user) if it is not running, and re-use the same environment variable values if it is already running. This site will give you some hints, but the exercise is left to the reader. http://live.gnome.org/GnomeKeyring/RunningDaemon You do need to initialize your keyring, which is what the Collabnet keyring_tool is for. -Steve
RE: Merge tracking bug - inherited merge-range
Now that I have a 1.7-alpha client, I gave this scenario I posted last month another try, and it works fine. Not a problem for 1.7. -Steve From: Varnau, Steve (Neoview) Sent: Monday, May 09, 2011 6:06 PM To: users@subversion.apache.org Cc: Brackett, Faye Subject: Merge tracking bug - inherited merge-range Greetings, I have a merge tracking bug to report. It seems like there are a lot of steps to re-produce it, but we discovered this in the real world, and it took a long while to figure out what was going on and to re-produce it. We are running 1.6.15 clients. We have lots of branching, and unfortunately svn:mergeinfo at multiple levels. This bug apparently only shows up if you merge two levels of directory that have new mergeinfo properties. The lower level directory does not get updated correctly and causes duplicate merge conflicts later. Yes, I know "best practice" says to merge only at the top-level, but in a large project, those merge-tracking properties can grow like weeds. The example steps below to reproduce use multiple branches just to produce the mergeinfo at multiple directory levels. There might be a simpler way to reproduce it. I did not find anything in the issue tracker, and I have not tried this with 1.6.16 or with pre-release 1.7. -Steve # create sub-directory tree $ svn co file:///c:/temp/svn-test/trunk trunk-wc $ cd trunk-wc/ $ svn mkdir subA $ svn mkdir subA/subB $ svn ci -m "need 2 directories" $ svn cp ^/trunk ^/branch/br1 # first branch adds some content $ cd .. $ svn co file:///c:/temp/svn-test/branch/br1 br1-wc $ cd br1-wc/subA $ touch foo $ touch subB/bar $ svn add foo subB/bar $ svn ci -m "br1 adds" # second project branch picks up the directories before project 1 delivers # third and forth start later $ cd ../.. $ cd trunk-wc/ $ svn cp ^/trunk ^/branch/br2 -m "victim project" $ svn merge --reintegrate ^/branch/br1 $ svn ci -m "" $ svn cp ^/trunk ^/branch/br3 -m "foo project" $ svn cp ^/trunk ^/branch/br4 -m "bar project" # three projects working concurrently, project 3 & 4 make changes $ cd .. $ svn co file:///c:/temp/svn-test/branch/br2 br2-wc $ svn co file:///c:/temp/svn-test/branch/br3 br3-wc $ svn co file:///c:/temp/svn-test/branch/br4 br4-wc $ cd br3-wc/subA/ $ echo "change" > foo $ svn ci -m "" $ cd ../../br4-wc/subA/subB/ $ echo "change" > bar $ svn ci -m "" # project 2 first synchs up the changes from br1 $ cd ../../../br2-wc/ $ svn merge ^/trunk $ svn ci -m "synch 1" $ svn up At revision 88. # project 3 & 4 each deliver content AND incidentally add svn:merginfo properties to subA & subB $ cd ../trunk-wc/subA/subB/ $ svn up $ svn merge --reintegrate ^/branch/br4/subA/subB $ svn ci -m "deliver bar" Committed revision 89. $ cd .. $ svn up $ svn merge --reintegrate ^/branch/br3/subA $ svn ci -m "deliver foo" Committed revision 90. # project 2 synchs up again, including svn:mergeinfo $ cd ../../br2-wc/ $ svn merge ^/trunk --- Merging r88 through r90 into '.': UsubA\foo UsubA\subB\bar U subA\subB U subA # at this point mergeinfo is correct for subA, but not for subB # The content looks okay, so we check in and try another synch merge # Even though nothing changed on trunk, we get duplicate merge conflict $ svn ci -m "synch 2" $ svn up At revision 91. $ svn merge ^/trunk --- Merging r82 through r87 into 'subA\subB': C subA\subB\bar Summary of conflicts: Tree conflicts: 1
RE: Apparently Spurious svn:merginfo
> -Original Message- > From: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: Tuesday, June 28, 2011 2:20 PM > To: Michael Fletcher; users@subversion.apache.org > Subject: RE: Apparently Spurious svn:merginfo > > > We are having problems with a large number of svn:mergeinfo > > properties > > being modified each time we merge. These svn:mergeinfo are on > > unrelated > > files to the actual change being made. Though it does seem as if > > they > > correlate to prior merges that have happened. If we commit these > > property changes they will happen again the next time we merge. > > > > At this point when we merge we will see 80 files with svn:mergeinfo > > changed when we might only be merging one file. It's becoming > > difficult > > to determine what exactly we have changed. > > > > I looked in the FAQ and googled and nothing exactly seemed to match > > what > > we are seeing. > > > > Mostly, we have TortoiseSVN 1.6.8 / Subversion 1.6.11 on the client > > and > > svn 1.6.15 on our server. The repository is old, having had nearly > > every major version of SVN that ever existed. > > > > We merge sometimes from our "trunk" to a branch and sometimes from > > our > > branches back to trunk. We often have multiple releases in flight > > so a > > fix will be merged from ^/branches/7.00.39 to ^/branches/7.00.40 > > and > > then to ^/branches/7.00.41 and then to ^/trunk. Or the reverse. > > > > At some point people were reverting the svn:mergeinfo properties > > and > > performing the checkin because they didn't know what they did. > > Nobody > > should be doing that any more. > > > > Any help would be appreciated. > > This is a pretty common complaint people have, I'm surprised you > couldn't find any threads about it. If I were writing an svn merging FAQ > this would probably be question number 1 or 2. > > What is most likely happening is that you have mereinfo on your child > nodes that is not present in your root node. This usually happens when > someone does a merge for a specific file or folder rather than doing the > merge at the project root. > > I was going to write all about this, but quickly was able to find this > article on line that saves me much typing. > > http://blog.syntevo.net/2011/03/16/130026864.html > > BOb It looks like the 1.7 merge command will make the problem a bit better in at least two ways. 1) It will only update mergeinfo on sub-trees that were affected in the merge, even if other sub-trees have mergeinfo properties. (I am probably not doing full justice to this change -- see http://subversion.apache.org/docs/release-notes/1.7.html#subtree-mergeinfo-recording.) 2) As the same link shows, the merge command will be more verbose about when it is updating meta-data versus merging content. Often times, people only merge a sub-tree because they know that the branch they worked on only changed content in that one tree. That's fine, but it adds more mergeinfo at the sub-tree level, instead of at the branch level. If you want to elide mergeinfo on lower levels, you can run record-only merge(s) at the higher level so that the mergeinfo property goes away at lower levels without actually removing data (you just move it up to a higher level). Of course you have to do the research to verify it is a safe/correct thing to do for that particular circumstance. I was headed down this path before getting side-tracked on to other work. One useful thing to know is which branch meta-data is different from one sub-tree to another. I just started comparing merge info on directory path versus another via this little script: #!/bin/bash dir=$1 if [[ $1 = "." ]] then svn pg svn:mergeinfo $1 else svn pg svn:mergeinfo $1 | sed -e "s,/$1:,:," fi That gives output stripped of relative path info so that they can be directly diff'ed to see which merges are missing in which sub-trees. Caveat: I am not sure that's a valid comparison in the future 1.7 world. -Steve
RE: branch sync with unversioned files results in versioned file being deleted when reintegrated
From: C L [mailto:cl_...@hotmail.com] Sent: Sunday, July 31, 2011 8:52 PM To: users@subversion.apache.org Subject: branch sync with unversioned files results in versioned file being deleted when reintegrated Hey all, I found this oddity today with a branch which had an unversioned file in a checkout, which I then synced up with a trunk which had a version of the file committed. "svn merge" reported the file skipped and a "svn status" afterwards didn't complain about conflicts. The merge was committed and then reintegrated into trunk, which promptly marked the file as being deleted. Anyone else encounter this? Yes, this is a common scenario. It is the easiest way to inadvertently lose content when merging. A common problem is that when you do a sync-up merge, which has new files they get added in your working copy. You revert the merge, and they get left in the working copy as private files (just like reverting any other added file). You then re-try the merge and to avoid over-writing your private files, they get skipped. The skipped messages get lost in the noise of a large merge, but you check for conflicts and finding none, you check in. As far as svn is concerned, you intentionally deleted those files in your branch. Re-integrating the branch removes them from trunk, (or parent branch). I tell our developers to always clean up private files after reverting a merge, but it is an easy thing to miss. By my understanding, there are some improvements coming in 1.7 which will considerably improve the situation -- better merge reporting and mergeinfo recording will not show a skipped file as merged. -Steve
Remote repository query
Hi, A few times we have found ourselves working on a design where we find ourselves unable to connect to the repository but would still like to be able to make modifications to our disconnected working copy. Is there any way commits can be made to a working copy and then somehow synced back into the main repository when connection can be established. I was thinking of things like a copy of the repo on the remote machine using file :// protocol or something like that. Thanks for any help you can give. Regards Steve Hutchinson This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
RE: Remote repository query
Thanks for the reply. We have been looking at git-svn but to be honest I was hoping for a cleaner svn solution if there was one. >> A few times we have found ourselves working on a design where we find >> ourselves unable to connect to the repository but would still like to > >be able to make modifications to our disconnected working copy. >You should look at real distributed version control, git for example has a svn >adapter, so you may be able to commit to a local git repo wherever you are >disconnected and sync >afterwards to svn. Mit freundlichen Grüßen, Thorsten Schöning This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
Managing Product templates
Hi, We are currently branching into Subversion usage operating with VisualSVN Server (will upgrade to Enterprise when trials are complete) and a client side using TortoiseSVN. In general all very happy and things are all pretty seamless and obvious, but... I would like to introduce the concept of a "product" directory template that would be resident in each of our repositories. I guess at this point I should say that we are probably going to operate with multiple repositories where a repository is set up for each of our main "Projects". Then inside each of our repositories we would have many "products", each hopefully having a structure generated from our template. The reason I think we will operate in this fashion is because we will need to apply specific user security access rights to the "projects" and I am told by our IT administrators that this would be the simplest way of achieving this. Open to pointers on this too. I have managed to create the template structure (applying desired properties to the structure such as ignore patterns and logminsize etc) and then create new "products" in a repository based on the template simple copy function in a Tortoise repo-browser, not really rocket science.. But I am struggling to find a way of say importing this template into another repository and identify a mechanism, however manual, of keeping them in sync. I am trying to achieve as much as possible from a client interface as in general we do not have simple access to personnel with server access rights. I apologise if this is the wrong place to post this query but my web searching has not really managed to help so far I would appreciate any guidance, even if it is a pointer to another place to ask the question. Thanks for any help that can be given. Regards Steve Hutchinson FPGA Group Leader E-Mail :steven.hutchin...@mbda-systems.com This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England. __ This email has been scanned by the MessageLabs Email Security System. For more information please visit http://www.messagelabs.com/email __
RE: Possible bug in svn's gnome-keyring support?
Jeremy, If svn is configured to use a Gnome keyring, then it is trying to store the password you are giving on the command line in the keyring. Hence it is prompting for the gnome-keyring password. If you also specify –no-auth-cache, then you might not get a prompt. -Steve From: Jeremy Wall [mailto:jw...@google.com] Sent: Tuesday, July 13, 2010 8:09 AM To: users@subversion.apache.org Subject: Possible bug in svn's gnome-keyring support? Hi, I noticed after updating svn to version 1.6.6 that svn now has gnome-keyring support. However It seems to ignore the --username --password flags if that support is enabled. I don't use the gnome-keyring or even gnome but subversion refused to let me commit until I turned off password-stores in the config despite giving it a valid username and password. Instead it would prompt for the gnome-keyring password which is not set up for me and refuse to continue until I successfully authenticated to the keyring. This seems like the wrong behavior to me. Is it intended? Here is my subversion information: svn, version 1.6.6 (r40053) compiled Dec 12 2009, 05:06:12 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Jeremy
RE: Possible bug in svn's gnome-keyring support?
It should only use gnome if it is specified in your config file (~/.subversion/config): password-stores = gnome-keyring -Steve From: Jeremy Wall [mailto:jw...@google.com] Sent: Tuesday, July 13, 2010 9:11 AM To: Varnau, Steve (Neoview) Cc: users@subversion.apache.org Subject: Re: Possible bug in svn's gnome-keyring support? The strangeness is it's insistence on using the Gnome Keyring despite me not using Gnome. Is this the expected default behaviour? On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview) mailto:steve.var...@hp.com>> wrote: Jeremy, If svn is configured to use a Gnome keyring, then it is trying to store the password you are giving on the command line in the keyring. Hence it is prompting for the gnome-keyring password. If you also specify –no-auth-cache, then you might not get a prompt. -Steve From: Jeremy Wall [mailto:jw...@google.com<mailto:jw...@google.com>] Sent: Tuesday, July 13, 2010 8:09 AM To: users@subversion.apache.org<mailto:users@subversion.apache.org> Subject: Possible bug in svn's gnome-keyring support? Hi, I noticed after updating svn to version 1.6.6 that svn now has gnome-keyring support. However It seems to ignore the --username --password flags if that support is enabled. I don't use the gnome-keyring or even gnome but subversion refused to let me commit until I turned off password-stores in the config despite giving it a valid username and password. Instead it would prompt for the gnome-keyring password which is not set up for me and refuse to continue until I successfully authenticated to the keyring. This seems like the wrong behavior to me. Is it intended? Here is my subversion information: svn, version 1.6.6 (r40053) compiled Dec 12 2009, 05:06:12 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme Jeremy
RE: Possible bug in svn's gnome-keyring support?
Also, I guess it could be getting options from system-wide config (/etc/subversion on linux). -Steve -Original Message- From: Mark Phippard [mailto:markp...@gmail.com] Sent: Tuesday, July 13, 2010 9:29 AM To: Jeremy Wall Cc: Varnau, Steve (Neoview); users@subversion.apache.org Subject: Re: Possible bug in svn's gnome-keyring support? If the option is not set, the default behavior is to use what is available. If you have gnome-keyring support it tries to use it. On Tue, Jul 13, 2010 at 12:22 PM, Jeremy Wall wrote: > There was no password-stores line in my config file. I had to add a > password-stores line to the file to disable it. Is there a second config > file it might be pulling from that I'm unaware of? > > On Tue, Jul 13, 2010 at 11:15 AM, Varnau, Steve (Neoview) > wrote: >> >> It should only use gnome if it is specified in your config file >> (~/.subversion/config): >> >> >> >> password-stores = gnome-keyring >> >> >> >> -Steve >> >> >> >> From: Jeremy Wall [mailto:jw...@google.com] >> Sent: Tuesday, July 13, 2010 9:11 AM >> To: Varnau, Steve (Neoview) >> Cc: users@subversion.apache.org >> Subject: Re: Possible bug in svn's gnome-keyring support? >> >> >> >> The strangeness is it's insistence on using the Gnome Keyring despite me >> not using Gnome. Is this the expected default behaviour? >> >> On Tue, Jul 13, 2010 at 11:08 AM, Varnau, Steve (Neoview) >> wrote: >> >> Jeremy, >> >> >> >> If svn is configured to use a Gnome keyring, then it is trying to store >> the password you are giving on the command line in the keyring. Hence it is >> prompting for the gnome-keyring password. If you also specify >> -no-auth-cache, then you might not get a prompt. >> >> >> >> -Steve >> >> >> >> From: Jeremy Wall [mailto:jw...@google.com] >> Sent: Tuesday, July 13, 2010 8:09 AM >> To: users@subversion.apache.org >> Subject: Possible bug in svn's gnome-keyring support? >> >> >> >> Hi, >> >> >> >> I noticed after updating svn to version 1.6.6 that svn now has >> gnome-keyring support. >> >> >> >> However It seems to ignore the --username --password flags if that support >> is enabled. I don't use the gnome-keyring or even gnome but subversion >> refused to let me commit until I turned off password-stores in the config >> despite giving it a valid username and password. Instead it would prompt for >> the gnome-keyring password which is not set up for me and refuse to continue >> until I successfully authenticated to the keyring. >> >> >> >> This seems like the wrong behavior to me. Is it intended? >> >> >> >> Here is my subversion information: >> >> >> >> svn, version 1.6.6 (r40053) >> >> compiled Dec 12 2009, 05:06:12 >> >> >> >> Copyright (C) 2000-2009 CollabNet. >> >> Subversion is open source software, see http://subversion.tigris.org/ >> >> This product includes software developed by CollabNet >> (http://www.Collab.Net/). >> >> >> >> The following repository access (RA) modules are available: >> >> >> >> * ra_neon : Module for accessing a repository via WebDAV protocol using >> Neon. >> >> - handles 'http' scheme >> >> - handles 'https' scheme >> >> * ra_svn : Module for accessing a repository using the svn network >> protocol. >> >> - with Cyrus SASL authentication >> >> - handles 'svn' scheme >> >> * ra_local : Module for accessing a repository on local disk. >> >> - handles 'file' scheme >> >> >> >> >> >> Jeremy >> >> > -- Thanks Mark Phippard http://markphip.blogspot.com/
SVN Externals 1.6 to 1.7 migration issue
Hi, We're been using 1.6 svn externals to manage a FW task. In the repository we have a folder structure (which is pretty much defined by the tools we are using) as below :- FOLDER A -> file_a1.txt, file_a2.txt, file_a3.txt FOLDER B -> file_b1.txt, file_b2.txt, file_b3.txt Then using externals we link to those folder to create a WC PROJECT structure that looks like :- PROJECT -> FOLDER C -> file_a1.txt, file_a2.txt, file_a3.txt AND file_b1.txt PROJECT -> FOLDER D -> file_b1.txt, file_b2.txt, file_b3.txt The externals on PROJECT FOLDER we used looked like (not actually using file protocol, just created for example purposes) :- file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_A FOLDER_C file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B FOLDER_D file:///D:/FPGA/SVN_ISSUE/repo/FOLDER_B/file_b1.txt FOLDER_C/file_b1.txt Worked ok with 1.6. We get the below error in 1.7 when updating of :- External failed: D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C\file_b1.txt Error: Cannot insert a file external defined on 'D:\FPGA\SVN_ISSUE\PROJECT' into the Error: working copy 'D:\FPGA\SVN_ISSUE\PROJECT\FOLDER_C'. We have tried a few things (will not share all at this point due to info overload), but wondered if there were any others that achieve something like this with 1.7 or could offer some advise ? Thanks for any help. Regards Steve H This email and any attachments are confidential to the intended recipient and may also be privileged. If you are not the intended recipient please delete it from your system and notify the sender. You should not copy it or use it for any purpose nor disclose or distribute its contents to any other person. MBDA UK Limited, a company registered in England and Wales, registration number 3144919 whose registered office is at Six Hills Way, Stevenage, Hertfordshire, SG1 2DA, England.
