svn merges with reintegrate confusion
Hi All We are using 1.6 SVN. We like to svn merge from our branch A to trunk. We have been diligent in svn merge from trunk to A. These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped. Now we like to merge branch A to trunk using --reintegrate option. But we dont know what to expect if using this option fails on us. 1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ? 2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ? Any help is appreciated. Sincerely
RE: svn log hang
Hi, It seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. I tried the nightly build of TortoiseSVN [1] svn, version 1.8.4-dev (under development) compiled Oct 16 2013, 23:05:56 on x86-microsoft-windows (as I was not able to compile the 1.8.x branch myself using Visual Studio 2008 because of a weird include path issue and the Subversion nightly build site of Mr. Wright [2] delivers only a 404 page) and I was not able to reproduce the issue using my test case so I guess it is fixed. Thank you! Regards, Stefan [1] http://nightlybuilds.tortoisesvn.net/latest/win32/full/ [2] http://people.apache.org/~hwright/svn/nightly/deploy/
Re: svn 1.8.3 on windows often crashes
W dniu 2013-10-14 22:01, Bob Archer pisze: W dniu 2013-10-04 15:04, Ivan Zhakov pisze: On 4 October 2013 17:00, Karol Szkudlarek ka...@mikronika.com.pl wrote: W dniu 2013-10-04 14:50, Ivan Zhakov pisze: On 4 October 2013 16:44, Ivan Zhakov i...@visualsvn.com wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Well, yes it looks like exactly my problem. Thanks for info about. When the 1.8.4 will be released? Now its very annoying crash. I do 'svn log' very often. :-) There is no specific schedule for patch releases. Usually they come not less often than every month and if important fixes are waiting for release. Subversion 1.8.3 was released 29 August 2013. Hello again Ivan, Now we have 14 of October (so we have roughly more then 1 month from 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. Please tell me ss it possible to back to 1.7.x series or not?! Of course it is. Of course, there is no way to downgrade a working copy that I am aware of, so you would have to do a clean checkout. BOb Hello again, I have 3 different and big source trees and compilation takes time. This is no option. Better if will be patch available or new 1.8.4 binaries. As I see they are still unavailable. According to http://subversion.apache.org/docs/release-notes/ 1.8.x is fully supported and from release notes is considered the current best release for me currently is step backward. KarolSzk.
authz via properties?
Hi all, We are actively using authz path-based authentication rules: due to some legal requirements, some parts of our product source code are not accessible to a part of the developer team. Currently authz does not support wildcards (there is an issue about that [1] discussed since 2006). Because of this, each time a branch is created, authz rules have to be copied and modified for the new branch. This leads to a proliferation of authz rules; our authz is currently about 2000 lines and growing. I am currently implementing a post-commit script so that we would be able to record authz rules on files/directories, and authz would be appended with new rules every time these files/directories are copied. First, I am wondering how well such 'authz' approach would scale. Has anyone run scalability tests on authz? Second, I thought that if I am using properties to track authz-controlled files, SVN server would probably do that more effectively than a post-commit script. As an added value, property-based authz would allow versioning in path-based auth configuration that current mechanism does not allow. E.g., currently one could either configure path /foo as either R/O, R/W or unaccessible to user U; it is not possible to configure the path to be unaccessible before/after a certain revision. Thoughts? Ideas? Regards, Alexey. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=2662
svn mergeinfo and svn merge - questions
Hi All We are using 1.6 SVN. We like to svn merge from our branch A to trunk. We have been diligent in svn merge from trunk to A. These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped. Now we like to merge branch A to trunk using --reintegrate option. But we dont know what to expect if using this option fails on us. 1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ? 2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ? 3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch. Any help is appreciated. Sincerely
RE: svn mergeinfo and svn merge - questions
1. You can use svn merge --dry-run if you are using command line or if you are using a client like tortoise then a test merge option should be available. This won't actually merge but show if there will be any failure in case an actual merge was performed. 2. Do the re-intergrate merges on your local copies and once it is complete (re-intergrate merge shouldn't most likely fail during the actual operation itself) you can resolve the conflicts during the commit to your subversion repositories (SVN Red Bean book for resolving conflicts explains things in detail) 3. Not sure about this From: Z W [mailto:mpc8...@gmail.com] Sent: Thursday, October 17, 2013 3:37 PM To: users@subversion.apache.org Subject: svn mergeinfo and svn merge - questions Hi All We are using 1.6 SVN. We like to svn merge from our branch A to trunk. We have been diligent in svn merge from trunk to A. These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped. Now we like to merge branch A to trunk using --reintegrate option. But we dont know what to expect if using this option fails on us. 1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ? 2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ? 3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch. Any help is appreciated. Sincerely Barclaycard www.barclaycardus.com This email and any files transmitted with it may contain confidential and/or proprietary information. It is intended solely for the use of the individual or entity who is the intended recipient. Unauthorized use of this information is prohibited. If you have received this in error, please contact the sender by replying to this message and delete this material from any system it may be on.
RE: svn mergeinfo and svn merge - questions
Hi All We are using 1.6 SVN. We like to svn merge from our branch A to trunk. We have been diligent in svn merge from trunk to A. These svn merges from trunk to branch A also include --record-only merges too, in addition to regular merges. Development on branch A has stopped. Now we like to merge branch A to trunk using --reintegrate option. But we dont know what to expect if using this option fails on us. 1) Suppose svn merge --reintegrate fails on us on a working copy that has all the mergeinfo list information. Could we perform a clean co of branch A into another working copy and then perform svn merge --reintegrate to trunk there ? Will we get more conflicts simply because the new working copy doesnt have the mergeinfo list like the first working copy of branch A ? Will this plan B work ? I'm not sure I follow. To reintegrate a branch into a trunk your merge target (the working copy) is the trunk. Having a branch checked out doesn't change this. 2) How do we resolve conflicts during svn merge --reintegrate process ? Would you share the steps for us to make the merge go smoothly ? It depends on the conflict. Generally, if it is a content conflict you use a 3-way merge tool to resolve the conflict. This is no different than if there is a conflict when you do an update. The other type is a tree conflict. Generally, these occur when the path that has a change in the repository doesn't exist in your merge target working copy. Resolving them depends on the conflict and you. For example, in branch you edited foo.cs, but in trunk that file is deleted. So, when you try to merge the edit you get a tree conflict. 3) Is mergeinfo a global or local property ? it seems that whenever a new checkout is done, mergeinfo list matches up with other working copies of the same branch. I'm not sure what you are asking here. Merge info is a subversion property, so of course it will exist whenever you check out. Just like and svn:mime-type property. BOb Any help is appreciated. Sincerely
Re: authz via properties?
[Restored CC of the mailing list] On Thursday, October 17, 2013 03:24:45 PM Mark Phippard wrote: On Thu, Oct 17, 2013 at 3:00 PM, Alexey Neyman sti...@att.net[1] wrote: We are actively using authz path-based authentication rules: due to some legalrequirements, some parts of our product source code are not accessible to apart of the developer team. Currently authz does not support wildcards (thereis an issue about that [1] discussed since 2006). Because of this, each time abranch is created, authz rules have to be copied and modified for the newbranch. This leads to a proliferation of authz rules; our authz is currently about2000 lines and growing. I am currently implementing a post-commit script sothat we would be able to record authz rules on files/directories, and authzwould be appended with new rules every time these files/directories arecopied. CollabNet TeamForge supports wildcard rules: http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge[2] Interesting. How did they deal with the concern raised in issue #2662 (i.e., the need to walk the tree below a certain path to check if any of the other rules apply to any descendant path)? First, I am wondering how well such 'authz' approach would scale. Has anyonerun scalability tests on authz? So your question is whether at a certain size does it slow down? I recall in the past it being said that it was stored in a hash so performance should not vary. But there has to be a parsing slow down and possible memory bloat. That said, I have heard of files in the hundred thousands for lines. Yes, that was the question. Note that you can also have files per repository. We do not want to split the repository unless absolutely necessary, as that would break the atomicity of commits for features touching both restricted and unrestricted parts of the repository. Instead, I think, it would be very handy if the access rights were copied along with the file/directory on which they are specified. Second, I thought that if I am using properties to track authz-controlledfiles, SVN server would probably do that more effectively than a post-commitscript. As an added value, property-based authz would allow versioning inpath-based auth configuration that current mechanism does not allow. E.g.,currently one could either configure path /foo as either R/O, R/W orunaccessible to user U; it is not possible to configure the path to beunaccessible before/after a certain revision. Someone could always contribute it. I do not think it would scale well but if it were optional then you could make the decision for yourself. Authz rules are expensive to apply. If SVN had to do additional repository I/O to check for and fetch properties it would only get worse. I'll probably have a stab at it. One of the goals of this post was to check if there are any objections to such feature that would make such development worthless /ab initio/. Regards, Alexey. [1] mailto:sti...@att.net [2] http://blogs.collab.net/teamforge/wildcard-access-control-and-path-based-permissions-in-teamforge
Re: authz via properties?
On Thu, Oct 17, 2013 at 5:39 PM, Alexey Neyman sti...@att.net wrote: ** [Restored CC of the mailing list] Did I only reply to you? Thanks for adding the list back. On Thursday, October 17, 2013 03:24:45 PM Mark Phippard wrote: So your question is whether at a certain size does it slow down? I recall in the past it being said that it was stored in a hash so performance should not vary. But there has to be a parsing slow down and possible memory bloat. That said, I have heard of files in the hundred thousands for lines. Yes, that was the question. Note that you can also have files per repository. We do not want to split the repository unless absolutely necessary, as that would break the atomicity of commits for features touching both restricted and unrestricted parts of the repository. Instead, I think, it would be very handy if the access rights were copied along with the file/directory on which they are specified. I was only pointing this out in case your existing rules were covering many repositories. If that were true, you can now have one authz file per repository rather than combining everything into a single file. -- Thanks Mark Phippard http://markphip.blogspot.com/
Re: svn 1.8.3 on windows often crashes
On 17.10.2013 18:08, Karol Szkudlarek wrote: W dniu 2013-10-14 22:01, Bob Archer pisze: W dniu 2013-10-04 15:04, Ivan Zhakov pisze: On 4 October 2013 17:00, Karol Szkudlarek ka...@mikronika.com.pl wrote: W dniu 2013-10-04 14:50, Ivan Zhakov pisze: On 4 October 2013 16:44, Ivan Zhakov i...@visualsvn.com wrote: I'm trying to use the latest 1.8.3 64-bit version of svn client: CollabNetSubversion-client-1.8.3-1-x64.exe but several times crashes. In attachement are log and dmp. Hi, The attached dumps and logs doesn't have debug symbols included, this we're unable to investigate the issue. I recommend you contact company produced this binaries (CollabNet) or try to reproduce problem with other Subversion binaries distribution and contact them. Well, I checked logs more carefully and it seems like issue #4425 [1] which is fixed in r1522892 and proposed for backport to Subversion 1.8.4. [1] http://subversion.tigris.org/issues/show_bug.cgi?id=4425 Well, yes it looks like exactly my problem. Thanks for info about. When the 1.8.4 will be released? Now its very annoying crash. I do 'svn log' very often. :-) There is no specific schedule for patch releases. Usually they come not less often than every month and if important fixes are waiting for release. Subversion 1.8.3 was released 29 August 2013. Hello again Ivan, Now we have 14 of October (so we have roughly more then 1 month from 1.8.3 release) and I'm still stuck with crashes of subversion 1.8.3. Please tell me ss it possible to back to 1.7.x series or not?! Of course it is. Of course, there is no way to downgrade a working copy that I am aware of, so you would have to do a clean checkout. BOb Hello again, I have 3 different and big source trees and compilation takes time. This is no option. Better if will be patch available or new 1.8.4 binaries. As I see they are still unavailable. According to http://subversion.apache.org/docs/release-notes/ 1.8.x is fully supported and from release notes is considered the current best release for me currently is step backward. Fully supported does not mean that anyone gets to dictate when we make a release. It means that we will fix bugs, and this bug has been fixed and will be in the next release. If you can't wait, you can always build your own binaries, or ask (or pay) someone else to do it. The sources are free; and this project does not create binaries anyway. If you're expecting commercial support, you will not find it on this list; but there are many companies that do offer it. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: authz via properties?
On 17.10.2013 20:00, Alexey Neyman wrote: Hi all, We are actively using authz path-based authentication rules: due to some legal requirements, some parts of our product source code are not accessible to a part of the developer team. Currently authz does not support wildcards (there is an issue about that [1] discussed since 2006). Because of this, each time a branch is created, authz rules have to be copied and modified for the new branch. This leads to a proliferation of authz rules; our authz is currently about 2000 lines and growing. I am currently implementing a post-commit script so that we would be able to record authz rules on files/directories, and authz would be appended with new rules every time these files/directories are copied. First, I am wondering how well such 'authz' approach would scale. Has anyone run scalability tests on authz? Second, I thought that if I am using properties to track authz-controlled files, SVN server would probably do that more effectively than a post-commit script. As an added value, property-based authz would allow versioning in path-based auth configuration that current mechanism does not allow. E.g., currently one could either configure path /foo as either R/O, R/W or unaccessible to user U; it is not possible to configure the path to be unaccessible before/after a certain revision. Thoughts? Ideas? Properties are not suitable for storing ACLs because they are immutable; i.e., you cannot change properties on committed files and directories. You need a different kind of structure, one that the Subversion repository does not have yet. In-repository ACLs are a feature that's we'd like to add to the new repository back-end that's being developed. But don't hold your breath; it will be several years before this is available. In the meantime, one authz file per repository (and preferably stored /in/ the repository, which is a new feature in 1.8) is IMO the best available option. You can also use the pre-commit and pre-revprop-change hooks and build your own authz system around those, but that's a lot of work. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. br...@wandisco.com
Re: authz via properties?
On Friday, October 18, 2013 02:46:39 AM Branko Čibej wrote: On 17.10.2013 20:00, Alexey Neyman wrote: Hi all, We are actively using authz path-based authentication rules: due to some legal requirements, some parts of our product source code are not accessible to a part of the developer team. Currently authz does not support wildcards (there is an issue about that [1] discussed since 2006). Because of this, each time a branch is created, authz rules have to be copied and modified for the new branch. This leads to a proliferation of authz rules; our authz is currently about 2000 lines and growing. I am currently implementing a post-commit script so that we would be able to record authz rules on files/directories, and authz would be appended with new rules every time these files/directories are copied. First, I am wondering how well such 'authz' approach would scale. Has anyone run scalability tests on authz? Second, I thought that if I am using properties to track authz-controlled files, SVN server would probably do that more effectively than a post-commit script. As an added value, property-based authz would allow versioning in path-based auth configuration that current mechanism does not allow. E.g., currently one could either configure path /foo as either R/O, R/W or unaccessible to user U; it is not possible to configure the path to be unaccessible before/after a certain revision. Thoughts? Ideas? Properties are not suitable for storing ACLs because they are immutable; i.e., you cannot change properties on committed files and directories. You need a different kind of structure, one that the Subversion repository does not have yet. Well, technically you can dump reload... But that's hardly maintainable, I agree. Are those ACLs you're describing going to be version-specific? In other words, will it be possible to specify that /foo/bar@2345 is r/w for user harry, but not accessible starting with revision 2346? Thanks for a pointer to that 1.8 feature, I forgot about that. That might make my task a bit easier. Regards,Alexey. -- Branko Čibej | *Director of Subversion* WANdisco // /Non-Stop Data/ e. br...@wandisco.com[1] [1] mailto:br...@wandisco.com
