Re: Modifying svn:log property: good or bad?
Here's a basic sh script syntax. # Check forbidden mergeinfo paths TXN_PATHS=$($SVNLOOK changed -t "$TXN" "$REPOS") # Grep for paths *not* in merge-allowed levels: /trunk, /branches/release/*,... TXN_PATHS=$(echo "$TXN_PATHS" | grep -Ev "^trunk/?$" | grep -Ev "^branches/release/\w+/?$" | grep -Ev "^branches/feature/\w+/?$") for TXN_PATH in "$TXN_PATHS" do ELEM_PATH=$(echo "$TXN_PATH" | cut -c 5-) MERGEINFO=$($SVNLOOK propget "$REPOS" svn:mergeinfo -t "$TXN" "$ELEM_PATH" 2>/dev/null) if [ ! "$MERGEINFO" = "" ]; then fail_forbidden_mergeinfo_path;fi done Brent From: Alfred von Campe To: Eric Johnson Cc: Subversion Users Sent: Friday, February 26, 2016 2:22 PM Subject: Re: Modifying svn:log property: good or bad? Eric: Would you mind sharing your (redacted if necessary) commit hook that enforces the policies you mentioned? Alfred On Feb 26, 2016, at 14:01, Eric Johnson wrote: We definitely enforce restrictions. We also log all revprop changes. Keep in mind that this information is key to establishing a historical record of what happened with your source code. If you're lawyers haven't advised you already, you might want to consider what happens if you ever get hauled into court, and need to testify about the quality of the historical information in your Subversion repositories. You want to keep the list of people that can change the revprops (and the revisions themselves) to an absolute minimum. Eric. On Fri, Feb 26, 2016 at 10:03 AM, Alfred von Campe wrote: Eric: Thanks for the feedback. Do you enforce just appending to the svn:log property or is that just the policy and everyone follows it? Same question for modifying the other recprops: do you enforce it or is it just policy? Alfred On Feb 26, 2016, at 12:42, Eric Johnson wrote: We looked at this problem, and decided that typos were not sufficient reason to tamper with history. However, committers sometimes forget critical information, such as the bug # associated with a commit, or other information critical to a useful audit trail. To avoid losing history, and yet allow for such critical information, our work-around is to allow changes to the svn:log property, but only allow appending to existing contents. Once we put that in, people stopped complaining. We don't allow users to change any other revprops. Eric. On Fri, Feb 26, 2016 at 7:40 AM, Alfred von Campe wrote: Is modifying the unversioned svn:log property considered bad practice? We’re about to upgrade to a new Subversion server at work, and the central group that manages that server will no longer allow modifications to unversioned properties. Their main reason is so that third party tools like Jira and Crucible, that have daemons that scan check-in comments for keywords and index the results, don’t have to be re-run again to re-index updated commits. They are recommending creating a property on all the files that were affected in a commit (the name/value of the property is not important), and then committing that change with the “correct” check-in comment. I can see their point, but sometimes you just want to correct a minor typo in a commit log. I’m just wondering what collective wisdom of this group is in regards to updating the svn:log property (or other unversioned properties)? Thanks, Alfred
Weird Behaviour: Files reverted that didn't show up in a status --no-ignore
We are running VisualSVN 1.9.3 server on a Windows box and a user's workspace is on a Centos6.5 Linux box.He had just done a "svn update" and the build failed. No conflicts as far as I can tell. The "svn status" showed the build artifacts and his modified files. As a suggestion, he would "svn revert -R ." all his changes. During the revert, it showed numerous other SVN element(cpp & h) files being reverted that he never touched and the "svn status --no-ignore" never showed. We tried reproducing it but no luck. I'm in the process of switching over a bunch of "old", hardened Clearcase folks to SVN so this little weirdness is never good to see. Any ideas??? Brent
Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore
It was 1.8.14 client. It just said "Reverted " and the subsequent "svn status" made no mention of the . Brent From: Johan Corveleyn To: webster.br...@rogers.com Cc: "users@subversion.apache.org" Sent: Thursday, March 3, 2016 3:29 AM Subject: Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore On Wed, Mar 2, 2016 at 9:53 PM, wrote: > We are running VisualSVN 1.9.3 server on a Windows box and a user's > workspace is on a Centos6.5 Linux box. > He had just done a "svn update" and the build failed. No conflicts as far > as I can tell. The "svn status" showed the build artifacts and his modified > files. As a suggestion, he would "svn revert -R ." all his changes. During > the revert, it showed numerous other SVN element(cpp & h) files being > reverted that he never touched and the "svn status --no-ignore" never > showed. We tried reproducing it but no luck. > > I'm in the process of switching over a bunch of "old", hardened Clearcase > folks to SVN so this little weirdness is never good to see. Would still be unexpected / weird, but: is it possible that those files were not really changed, but that 'revert' simply generated unnecessary notifications (showing 'reverted file X' for files that weren't really changed)? You didn't mention the version of svn client. Maybe it's a notification bug in the client that's already fixed? -- Johan
Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore
These files were never changed in the first place, that's the weird part.We aren't using any local locks in the repo. Brent From: Johan Corveleyn To: webster.br...@rogers.com Cc: "users@subversion.apache.org" Sent: Wednesday, March 9, 2016 4:10 AM Subject: Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore On Sat, Mar 5, 2016 at 12:50 AM, wrote: > It was 1.8.14 client. > > It just said "Reverted " and the subsequent "svn status" made no > mention of the . Okay. I guess you cannot investigate anymore whether the content of those files was really reverted (changed), or whether it was just some uninteresting notification, without changing the content of the files (for instance because the writability of the files was changed, like Bert said: "One known case of this would be if some files were not writable. svn revert will restore writability/non writability based on whether a local lock is owned and/or svn:needs-lock is set, while status doesn't report this as a modification."). It might be interesting, in order to verify Bert's hypothesis, to check whether those notifications happened on files with the svn:needs-lock property or not (and whether or not the user had a lock on them or not). If you could reproduce this, it would be interesting to find out whether a content change happened, or only some metadata like the writability case. -- Johan
What's the process when converting a directory to use svn:externals?
Server 1.9.3 (Windows) and client 1.8.15(Linux-Centos6.5) We are in the mist of refactoring our directory structure from the monolithic (Clearcase imported) directory structure to moving subdirectories to new repositories and using svn:externals with pegged versions back into the primary product repository. No big deal but my user base is complaining about two big problems: tree conflicts and merging issue: "svn: E195020: Cannot merge into mixed-revision working copy [8:9775]; try updating first" but running "svn update" will not solved the problem. I want this conversation to just discussion the process of converting a directory to use svn:externals. I'll start another topic on the mixed revision issue. The problem I have is these subdirectories have build artifacts in them so when a "svn delete" is performed, the subdirectory remains. So whether a single update where the "svn delete" and the new svn:externals are defined or it is broken up into two updates, I get tree conflicts. I assuming I'm answering my own question here but I believe I need the two updates and I send out instructions to my user base to update to the 1st revision, manually the local subdirectories and then update to the 2nd revision. Anyone see a way to simplify this? Brent
Round 2: Merge error with mixed-revisions but subsequent "svn update" doesn't fix it
Env: Server 1.9.3 (Windows) and client 1.8.15(Linux-Centos6.5) being run by all users. We are in the mist of refactoring the directory structure. i.e. What's the process when converting a directory to use svn:externals?: http://mail-archives.apache.org/mod_mbox/subversion-users/201603.mbox/%3C1820009612.5161618.1457534793008.JavaMail.yahoo%40mail.yahoo.com%3E When the merge issue: 'svn: E195020: Cannot merge into mixed-revision working copy [8:9775]; try updating first" raised its ugly head again. Running a"svn update' don't solve the merge error. The svnversion command is reporting 8:9775 where 9775 is the revision of this WC's primary repo/URL while 8 is the pegged version of the latest directory that was converted from a fully checked in directory to a svn:externals. I'm having no luck reproducing the problem so I can run some of the suggested workarounds: "svn update --ignore-externals" or execute "svn update -r XXX" with an explicit revision. I know as the directory refactoring stabilizes, I hoping these issues will disappear but for now I have 100+ users that don't need this headache. My only solution is to delete and recreate the WC which is a hour+ checkout. Brent
Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore
Johan, thanks for the insights/efforts. Sorry about html --- damm Yahoo mail. It is possible that these files were chmod'd but I can't confirm now. It is good to know that changing file permissions won't be detected by a "svn status" but will get reverted. I've got 100+ exClearcase designers that love to point out every quirk in SVN. I definitely would be preferable if "svn status" and "svn revert" use the same concept of changes. Again, thanks for the help. Brent From: Johan Corveleyn To: webster.br...@rogers.com Cc: "users@subversion.apache.org" Sent: Wednesday, March 9, 2016 7:10 PM Subject: Re: Weird Behaviour: Files reverted that didn't show up in a status --no-ignore [ Please, if possible, use plain-text on this mailing list, and use bottom-posting (putting your reply at the bottom, or inline to the thing you're replying to). More below ... ] On Wed, Mar 9, 2016 at 3:08 PM, wrote: > These files were never changed in the first place, that's the weird part. > We aren't using any local locks in the repo. Okay, so definitely a "non-content-changing" revert then. So we're talking about needless notifications by revert, possibly scaring users. I've quickly tried to reproduce it, based on Bert's explanation of read-onlyness changes. No need for locks or the svn:needs-lock property. Just make a file read-only, and run a recursive revert. The file is made writable again, and revert notifies: [[[ C:\Temp\svntest>svn --version -q 1.9.3-SlikSvn C:\Temp\svntest>svnadmin create repos C:\Temp\svntest>svn co file:///c:/Temp/svntest/repos wc Checked out revision 0. C:\Temp\svntest>cd wc C:\Temp\svntest\wc>echo This is file 1 > file1.txt C:\Temp\svntest\wc>svn add *.txt A file1.txt C:\Temp\svntest\wc>svn ci -mm Adding file1.txt Transmitting file data ..done Committing transaction... Committed revision 1. C:\Temp\svntest\wc>attrib +R file1.txt ### (making read-only) C:\Temp\svntest\wc>svn st C:\Temp\svntest\wc>svn revert -R . Reverted 'file1.txt' ]]] Is this similar to what could have happened, Brent? I'm assuming it's not Windows-specific, because you reported the problem for a 1.8.14 svn client on Centos6.5 Linux. Maybe other variants of changes in permissions, executability or file ownership also give the same behaviour. I agree this is an issue, but I'm not sure if there is only one issue or two :-). 1) Is it OK for revert to change file metadata? Is that intended behaviour? Maybe it's OK for revert to change file metadata if the file also has content-changes that need to be reverted, but not if the file only has metadata-changes? 2) If we revert metadata-only-changed files, should revert notify about this? If it notifies for a metadata-only change, maybe the notification should indicate this? H -- Johan
Access control to stop creation of files/directories but allow svn:mergeinfo to be updated
As the subject line states I want access control to prevent the creation of files and directories at a certain directory level and above. Below that point, the general population can make whatever changes they deem fit. Another requirement I have is to always merge from the top level but that top level can only be "generally" written be a small group of architects. With these two conflicting requirements, I need a way to control the read/write access for files/directories but ensure the svn:mergeinfo can be written in this top level write protected directory. I've used the HTTPD access file before but I'm no longer the admin for the SVN server and it just provides general r/w access. I've used various perl/ini scripts to provide access control (i.e https://github.com/qazwart/SVN-Precommit-Kitchen-Sink-Hook/blob/master/pre-commit-kitchen-sink-hook.pl) but currently the admins for Windows based VisualSVN server recommend using python. It is looking like this custom pre-commit hook script will need to differentiate svn:mergeinfo property changes from the general changes. Then query for general access control hopefully with an existing python/ini solution else allow the svn:mergeinfo to fall through and be checked by the pre-revprop-change hook script. Other suggestion/comments would be greatly appreciated. Brent
Re: Blank lines
You should wrapper the diff command svn diff --diff-cmd 'diff -x -w' Brent From: Branko Čibej To: users@subversion.apache.org Sent: Wednesday, May 4, 2016 11:01 PM Subject: Re: Blank lines On 04.05.2016 22:58, Daniel Shahaf wrote: > Eric Johnson wrote on Wed, May 04, 2016 at 09:42:53 -0700: >> On 5/4/16 4:43 AM, Dariusz Staniak wrote: >>> How can I force >>> svn status >>> not to indicate files with added/removed blank lines as modified? >> You can't. Subversion has to treat all changes to files as relevant. >> Consider something like Markdown - an extra blank line means a paragraph >> break. In code, where inserting a blank line might help readability. > Not quite. > > Internally, Subversion does have to use strict byte-for-byte comparisons > (since committed files are preserved byte-for-byte in the repository). > > However, that has no bearing on the sense of comparison user-facing > logic, such as 'diff' and 'status', should use: these could implement > any sort of comparison deemed useful. In particular, it might be useful > for them to also be able to answer the question "What are all the files > that have non-whitespace changes?". Not 'status' -- 'svn status' should always show what 'svn commit' will send to the server. But 'diff', I agree, could be smarter. For example, right now, 'svn diff --summarize -x -w' will mention files that contain only whitespace changes, even though 'svn diff -x -w' will show an empty diff for those files. -- Brane
My mixed revision working copy remains after a 'svn update'
My mixed revision working copy remains mixed revision after multiple attempts with 'svn update'.Here's the final status output: [linux] >> svn st -u X vobs/common/cpCommon X vobs/common/dclCommon X vobs/ots/broadcom/BCM_SDK_6.4.11 X vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API X vobs/ots/osm4/Target/PldImages/lim400g_1 X vobs/ots/osm4/Tests/framework/tl1probe/mteraiv X vobs/ots/uboot/u-boot-2009.06 X vobs/ots/uboot/u-boot-2013.01.01 X vobs/ots/wrlplat/tlab_qemuppc X vobs/ots/wrlplat/tlab_xeoncore50 X vobs/ots/wrlplat/tlabqoriq50_small X vobs/prod Status against revision: 13673 Performing status on external item at 'vobs/ots/osm4/Target/PldImages/lim400g_1': Status against revision: 87468 Performing status on external item at 'vobs/ots/uboot/u-boot-2009.06': Status against revision: 475 Performing status on external item at 'vobs/common/cpCommon': Status against revision: 101 Performing status on external item at 'vobs/common/dclCommon': Status against revision: 101 Performing status on external item at 'vobs/ots/uboot/u-boot-2013.01.01': Status against revision: 475 Performing status on external item at 'vobs/ots/wrlplat/tlab_xeoncore50': Status against revision: 539 Performing status on external item at 'vobs/prod': Status against revision: 1290 Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6.4.11': Status against revision: 614 Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv': X vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library Status against revision: 2575 Performing status on external item at 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library': Status against revision: 65663 Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_small': Status against revision: 672 Performing status on external item at 'vobs/ots/wrlplat/tlab_qemuppc': Status against revision: 403 Performing status on external item at 'vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API': Status against revision: 73002 [Linux] >> svnversion 475:13673S There are two 'uboot' svn:externals pegged at 475 so I deleted the parent directory (i.e. rm -rf vobs/ots/uboot) and did another 'svn update' but that didn't clean it up. The svnversion is still reporting 475:13673S. The svn client version is 1.8.14. Thanks in advance for any insights. Brent Brent
Re: My mixed revision working copy remains after a 'svn update'
Yes, these externals are deliberately pegged and I have other working copies(WC) based on the exact same checkout and they show up as a single and not a mixed revision WC. Of the 108 WCs I've looked at, 36 are in a mixed-revision configuration and that's OK but in several cases, these WCs cannot be updated back to a single revision configuration. As well, the svnversion command is indicating that these WCs are 'Switched' but that has not been the case, they have never been switched. At this point, I'm recommending to my users to delete any WC that cannot by configured back into a single revision WC. Comments, suggestions, recommendations would be great. Brent From: Ryan Schmidt To: webster.br...@rogers.com Cc: Subversion Users Sent: Wednesday, August 17, 2016 12:49 AM Subject: Re: My mixed revision working copy remains after a 'svn update' > On Aug 16, 2016, at 2:54 PM, webster.br...@rogers.com wrote: > > My mixed revision working copy remains mixed revision after multiple attempts > with 'svn update'. > Here's the final status output: > > [linux] >> svn st -u > X vobs/common/cpCommon > X vobs/common/dclCommon > X vobs/ots/broadcom/BCM_SDK_6.4.11 > X vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API > X vobs/ots/osm4/Target/PldImages/lim400g_1 > X vobs/ots/osm4/Tests/framework/tl1probe/mteraiv > X vobs/ots/uboot/u-boot-2009.06 > X vobs/ots/uboot/u-boot-2013.01.01 > X vobs/ots/wrlplat/tlab_qemuppc > X vobs/ots/wrlplat/tlab_xeoncore50 > X vobs/ots/wrlplat/tlabqoriq50_small > X vobs/prod > Status against revision: 13673 > > Performing status on external item at > 'vobs/ots/osm4/Target/PldImages/lim400g_1': > Status against revision: 87468 > > Performing status on external item at 'vobs/ots/uboot/u-boot-2009.06': > Status against revision: 475 > > Performing status on external item at 'vobs/common/cpCommon': > Status against revision: 101 > > Performing status on external item at 'vobs/common/dclCommon': > Status against revision: 101 > > Performing status on external item at 'vobs/ots/uboot/u-boot-2013.01.01': > Status against revision: 475 > > Performing status on external item at 'vobs/ots/wrlplat/tlab_xeoncore50': > Status against revision: 539 > > Performing status on external item at 'vobs/prod': > Status against revision: 1290 > > Performing status on external item at 'vobs/ots/broadcom/BCM_SDK_6.4.11': > Status against revision: 614 > > Performing status on external item at > 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv': > X > vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library > Status against revision: 2575 > > Performing status on external item at > 'vobs/ots/osm4/Tests/framework/tl1probe/mteraiv/TL1_Library': > Status against revision: 65663 > > Performing status on external item at 'vobs/ots/wrlplat/tlabqoriq50_small': > Status against revision: 672 > > Performing status on external item at 'vobs/ots/wrlplat/tlab_qemuppc': > Status against revision: 403 > > Performing status on external item at > 'vobs/ots/osm4/Apps/HalServer/Drivers/lim400/Lim400API': > Status against revision: 73002 > > [Linux] >> svnversion > 475:13673S > > There are two 'uboot' svn:externals pegged at 475 so I deleted the parent > directory (i.e. rm -rf vobs/ots/uboot) and did another 'svn update' but that > didn't clean it up. The svnversion is still reporting 475:13673S. > > The svn client version is 1.8.14. > > Thanks in advance for any insights. Presumably, those externals were deliberately pegged to those revisions, so this is behaving as intended. If you want those externals to point to newer versions, change the revision in the svn:externals property, then svn update again.
Re: My mixed revision working copy remains after a 'svn update'
As an amendment, I created one more WC with my 1.8.16 svn client at the original XXX revision. (i.e. prior to the directory deletion and subsequent addition of the svn:externals). I then updated the client to 1.9.4 and ran the 'svn update' where it successfully deleted the directory and then added the svn:externals to overlay the same directory name from another repository. When I ran 'svnversion', it reported back a single revision and not Switched. -- It worked So I have a solution, if my users haven't already done a 'svn update' with the older 1.8.xx client. But is there anyway to fix an already updated WC with the svnversion command reports it as a switched mix revision WC? Brent From: Brent Webster To: subversion-users Cc: users@subversion.apache.org; webster.br...@rogers.com Sent: Thursday, September 1, 2016 1:58 PM Subject: Re: My mixed revision working copy remains after a 'svn update' I was able to reproduce the problem. When we migrated from Clearcase to SVN, all the separate VOBs that made up our product (as well as several other products) were copied into one large repository. The other products are now migrating from Clearcase so we need to emulate some of the common VOB directory structure by moving the contents of these common directories into separate repositories and then use svn:externals across these multiple products to include this common code back into each product. The problem is the original large repository where we need to delete the contents of these common directories and then add svn:externals to reference the new common code from these other repositories. The scenarios: I have three working copies(WCs): ws0, ws1 and ws2 that are all checked out from the same branch/revision: 1/ ws0 is where I will perform the deletion of the broadcom 6.3.5 directory, commit it and then add the svn:externals as a 2nd commit. Note: If we deleted the directory and then defined the svn:externals with the same name as one commit, it resulted in directory tree conflicts. e.g. rev XXX is the original revision, XXX+1 is the deletion of the broadcom directory and XXX+2 is the definition of the svn:externals When I run the 'svnversion' command, it reports back a single revision: XXX+2 2/ So ws1 is at revision XXX and 'svn update -r XXX+1' that deletes the broadcom directory and updates the WC successfully. Then a second 'svn update' is run that creates the new svn:externals of the same name as the broadcom directory When I run the 'svnversion' command, it reports back a single revision: XXX+2 3/ So ws2 is at revision XXX and a 'svn update' will do both the delete of the existing broadcom directory and then create the new svn:externals of the same name as the broadcom directory. It fails with the following warning: svn: warning: W155009: Failed to run the WC DB work queue associated with '/home/bwebste1/svn/ws2/broadcom/BCM_SDK_6.3.5', work item 1 (file-install broadcom/BCM_SDK_6.3.5/sdk-all/systems/linux/user/groove-2_6/Makefile 1 0 1 1) Updated to revision 14012. svn: E205011: Failure occurred processing one or more externals definitions Running 'svnversion' reports back a switched mixed revision WC i.e. 285:14012S where 285 is the pegged revision of the new svn:externals and 14012 is the XXX+2 revision of this product's repository. When I run a subsequent 'svn update', it reports the following: Updating '.': Fetching external item into 'broadcom/BCM_SDK_6.3.5': svn: warning: W155037: Previous operation has not finished; run 'cleanup' if it was interrupted At revision 14012. svn: E205011: Failure occurred processing one or more externals definitions Running 'svn cleanup' or 'svn cleanup --include-externals' has no affect. I then upgraded my svn client from 1.8.16 to 1.9.4 but no change either. The 'svnversion' still reports the workspace as a Switched mixed revision WC. At this point, I can only recommend the following: If the designer does not require to execute the 'svn merge' command then this WC is OK for use else delete it and create a new WC. Any better solutions?. On Tuesday, August 16, 2016 at 3:55:41 PM UTC-4, webste...@rogers.com wrote: My mixed revision working copy remains mixed revision after multiple attempts with 'svn update'.Here's the final status output: [linux] >> svn st -u X vobs/common/cpCommon X vobs/common/dclCommon X vobs/ots/broadcom/BCM_SDK_6.4. 11 X vobs/ots/osm4/Apps/HalServer/ Drivers/lim400/Lim400API X vobs/ots/osm4/Target/ PldImages/lim400g_1 X vobs/ots/osm4/Tests/framework/ tl1probe/mteraiv X vobs/ots/uboot/u-boot-2009.06 X vobs/ots/uboot/u-boot-2013.01. 01 X vobs/ots/wr
