Subversion 1.8 appreciation thread
Hi *,
I'm currently checking out (no pun intended) Subversion 1.8 RC2 and
thought a "Subversion 1.8 goodies" thread might be fun. Here we go...
Goodie #1:
Are you multitasking all day long?
Are you tired of remembering all those fancy changelist names you came
up with to keep the chaos in check?
Well, fret no more. Let your tab key do the thinking!
Simply create a shell script called svn-changelists with this content:
#!/bin/bash
dir=$PWD
while [[ ${#dir} != 0 ]]; do
if [[ -r $dir/.svn/wc.db ]]; then
sqlite3 $dir/.svn/wc.db 'select distinct(changelist) from actual_node;'
break;
fi
dir=${dir%/*}
done
Now use it in your favority shell's completion feature. I'm using
good-ol' tcsh, so that's
complete svn 'n@--changelist@`svn-changelists`@' [...]
Conclusion:
SQLite rulz! ;-)
Re: Subversion 1.8 appreciation thread
Goody #2: (People probably came up with something like this for Subversion 1.7 already... anyway...) Our company currently uses Subversion 1.6 and at first I thought 'duel-Subversioning' 1.6 and 1.8 would lead nowhere except headaches. As it turns out, the fact that a Subversion 1.8 client cannot directly work with a Subversion 1.6 working copy is no problem at all, at least not on GNU/Linux in a shell or GNU Emacs. First, make sure you have both Subversion versions installed and that you have links on your $PATH named svn-1.6 and svn-1.8 that link to the respective binaries. Then create a shell script called svn with this content: (work in progress) --- snip --- #!/bin/bash # check whether the command uses Subversion 1.8 features: usesNewFeature=0 for arg in "$@"; do if [[ "$arg" = "--search" || "$arg" = "--diff" || "$arg" = "--new" || "$arg" = "--old" ]]; then usesNewFeature=1; break; fi done if [[ "$1" = "upgrade" || ( "$1" = "help" && "$2" = "upgrade" ) ]]; then usesNewFeature=1; fi # decide which Subversion version to use: if [[ $usesNewFeature = 0 && -f .svn/entries && "`head -1 .svn/entries`" != "12" ]]; then cmd=svn-1.6 else cmd=svn-1.8 fi # debug logging: # echo `date` "[PWD=$PWD]" -- $cmd "$@" >>~/.svn.log exec $cmd "$@" --- snip --- There you go. A svn command that is able to deal with 1.6 and 1.8 working copies. Those are the two goodies I came up with so far. Who's next? Kind regards, Tobias
Re: large db/revs files
Thanks for everyone’s replies. Took me a couple days to review the links everyone sent. Thorsten’s links sent me to several of your posts, Mark -- thanks. Based on your feedback it appears the new release of svn within a month or so should resolve the problem. It appears the best solution is to wait until then. But, I did want to follow-up on the questions Thorsten & Olli had. Here is an example of our directory structure: projectA/ trunk/ tags/ release100_06062013_0809/ release100_06062013_0810/ … branches/ The tags are at the same directory level, which supports the inclination you had, Thorsten. I wasn’t aware that tagging a directory replicates the complete directory structure in db/res, which contains the largest files in our repo. The other directories are reasonable. The source of the largest db/rev repo, which has 141,573 revisions, is 780K. If I understand the skip-delta cost, which I may not completely, it sounds like each tagged release based on the trunk will occupy more space as it is farther away from the trunk revision number? Thanks. André Harper
Re: Tree conflict on Fresh checkout
So, is there additional information I can provide - would doing a diff on the properties of MkImage show anything useful.. I couldn't see any myself but perhaps there's some flags to get additional detail? On Wed, Jun 5, 2013 at 5:00 PM, Andrew Reedick wrote: > > > > From: James Hanley [mailto:jhan...@dgtlrift.com] > > Sent: Tuesday, June 04, 2013 1:44 PM > > To: users@subversion.apache.org > > Subject: Tree conflict on Fresh checkout > > > > Amy_project_03b_pristine/Project/settings/MkSharedData.exe > > C my_project_03b_pristine/Project/settings/MkImage > > A my_project_03b_pristine/Project/settings/MkImage/main.c > > A my_project_03b_pristine/Project/settings/MkImage/defs.h > > A my_project_03b_pristine/Project/settings/MkImage/Makefile > > Amy_project_03b_pristine/Project/settings/hex_to_hex.exe > > > > user_dude@computer_node~/projects/my_project/my_project_03b_pristine > > $ svn status > > D C Project/settings/MkImage > > > local unversioned, incoming add upon update > > D Project/settings/MkImage/Makefile > > D Project/settings/MkImage/defs.h > > D Project/settings/MkImage/main.c > > Summary of conflicts: > > Tree conflicts: 1 > > Duh. The 'C' is in the 2nd column, which means there's a conflict with > the properties. However, I'm not sure why you would have a properties > conflict on a checkout in svn 1.7. > > > >
A couple of questions, please... (UNCLASSIFIED)
Classification: UNCLASSIFIED Caveats: NONE Hi, I've been tasked to get a Certificate of Networthiness (CON) from the U.S. government so we can use Apache Subversion for version control. I've been using it for several years at home and I love it. 1. Is there perhaps a CON already? I've looked and saw an older one for Collabnet Subversion. 2. I'm filling out the form to apply for the CON, and I need a phone number and an address. Is that possible? That's it for now. Thank you in advance for your time and help. Respectfully, Stefan Stefan Doughty GaN Contractor 254-288-1914 stefan.doug...@gancorp.com stefan.j.doughty@mail.mil Classification: UNCLASSIFIED Caveats: NONE smime.p7s Description: S/MIME cryptographic signature
preventing accidental commit
I'm using Subversion on an Apache project (UIMA). Apache has standardized on a release process whereby the release happens when changes are committed to the dist.apache.org/repos/dist/release/... Our build process, for one part of our distribution (our "Eclipse Update Site"), for a new release, adds some files and replaces others at the distribution point (the replaced files are the "catelog" of the list of versions of various plugins, and other metadata). To do this, one proposed approach is to a) checkout the part of the update site from the ...dist/release... spot; b) update that, changing some files, adding others c) put it somewhere for a vote, and after the vote passes, d) commit the changes to the ...dist/release... spot This would work fine, I think. What I'm hoping to find out how to do is how to prevent the Release Manager from accidentally committing this before the vote passes. What I'd like is some kind of lock that would prevent the same user who checked out the files, from committing. I almost thought the svn lock mechanism would work, but it doesn't prevent the same user from doing the commit. What is the best approach? One person suggested I use an ant task run as part of the Maven build to rename the checked-out ".svn" files to ".hidesvn" - then the commit would not work (of course), until another action was taken to rename these back to .svn. Would that work? Is there a better approach? -Marshall Schor P.S., one other complexity: Our project is built using Maven and follows the conventions for that. We have a project for building the Eclipse Update Site, which is checked into our source SVN (not the dist.apache.org one). This project has a "target/" directory, which is "svn-ignored" by the source SVN repository. All the work in building a release is done inside this target/ directory, including step "a" above - which results in having the target/ marked "svn-ignore" by the source SVN checkout, containing inside it a directory which is a checkout of the dist/release... SVN. According to the svn book, this is allowed :-), but may affect the renaming "trick" (of .svn files) proposed above.
Re: preventing accidental commit
On Thu, Jun 06, 2013 at 02:46:16PM -0400, Marshall Schor wrote: > a) checkout the part of the update site from the ...dist/release... spot; > b) update that, changing some files, adding others > c) put it somewhere for a vote, and after the vote passes, > d) commit the changes to the ...dist/release... spot When you say "accidental commit", do you mean the release manager is running 'svn commit' on a working copy from dist.a.o instead of an unrelated working copy the commit was intended to be made from, not realising the mistake until the commit has been made? Or do you mean the release manager intentionally publishing the release, not realising that votes are outstanding? In which case I don't think there is a good technical solution to the problem. Perhaps the release manager needs a break :) In the first case: Why don't you commit to and vote in dev/release, and when all votes have passed, move the files to dist/release using svnmucc? This is what we do in Subversion itself. See this script: https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py This approach makes it very unlikely that release artifacts end up in the dist/release directory by accident.
Re: preventing accidental commit
On 6/6/2013 3:12 PM, Stefan Sperling wrote: > On Thu, Jun 06, 2013 at 02:46:16PM -0400, Marshall Schor wrote: >> a) checkout the part of the update site from the ...dist/release... spot; >> b) update that, changing some files, adding others >> c) put it somewhere for a vote, and after the vote passes, >> d) commit the changes to the ...dist/release... spot > When you say "accidental commit", do you mean the release manager > is running 'svn commit' on a working copy from dist.a.o instead > of an unrelated working copy the commit was intended to be made > from, not realising the mistake until the commit has been made? > > Or do you mean the release manager intentionally publishing the > release, not realising that votes are outstanding? In which case > I don't think there is a good technical solution to the problem. > Perhaps the release manager needs a break :) > > In the first case: > Why don't you commit to and vote in dev/release, and when all votes > have passed, move the files to dist/release using svnmucc? > This is what we do in Subversion itself. See this script: > https://svn.apache.org/repos/asf/subversion/trunk/tools/dist/release.py > This approach makes it very unlikely that release artifacts > end up in the dist/release directory by accident. One issue we thought about when considering using .../dev/... was "wasting space" in SVN with (potentially multiple) release candidates (which were binary artifacts, like compressed Jar files). Because of this, we were trying to avoid using .../dev/... for this. But, if that is an unnecessary worry, and we go with using .../dev/..., it would seem that the first step in this would be to do an svn copy in dist.apache.org from /release/... to /dev/... and then check out from /dev/. The reason for the svn-copy from .../release/... to .../dev/... is because we need to "guarantee" that we're incrementally building against the previous "release" version; who knows what may have happened inside /dev/ since the last release. The release manager could then commit the "candidate" to /dev/, and when it is finally voted out, copy dev -> release for that part. One thing I don't understand about SVN is how the svn copy works when copying from one repository location to another, when files already may exist at the target spot. The svn book I think is silent on this issue (unless I missed it) - the use cases talked about (like for branching and tagging) all seem to assume that the target spot "path" exists except for the last name segment (with an optional flag "--parents" to add multiple new path segments at the end). Is it a requirement that the target spot (including the last name in the path) for svn -> svn copying not already exist? If so, I guess the thing to do would be an svn delete of the target spot, followed by an svn copy. Does this sound right? Thanks. -Marshall
Re: preventing accidental commit
Guten Tag Marshall Schor, am Donnerstag, 6. Juni 2013 um 22:37 schrieben Sie: > One issue we thought about when considering using .../dev/... was "wasting > space" in SVN with (potentially multiple) release candidates (which were > binary > artifacts, like compressed Jar files). Because of this, we were trying to > avoid > using .../dev/... for this. If this is an issue depends on your binary files and your repository version and configuration. If the files contain a lot of similar data and just differ e.g. in timestamps in manifest files and your repo is current enough and has repository sharing enabled, which is the default, there should be any need to worry too much about wasting space as subversion will save identical data only once. With Subversion 1.8 this seems to be enhanced even further to be able to find duplicates within the same commit, opposed to former commited data in earlier versions. > One thing I don't understand about SVN is how the svn copy works when copying > from one repository location to another, when files already may exist at the > target spot. Just test it, I simply copied one folder to an already existing place and at least TortoiseSVN asked me if I won't to overwrite the target folder and it simply got committed as replaced. Mit freundlichen Grüßen, Thorsten Schöning -- Thorsten Schöning E-Mail:thorsten.schoen...@am-soft.de AM-SoFT IT-Systeme http://www.AM-SoFT.de/ Telefon...05151- 9468- 55 Fax...05151- 9468- 88 Mobil..0178-8 9468- 04 AM-SoFT GmbH IT-Systeme, Brandenburger Str. 7c, 31789 Hameln AG Hannover HRB 207 694 - Geschäftsführer: Andreas Muchow
Re: A couple of questions, please... (UNCLASSIFIED)
On Jun 6, 2013, at 11:01, "Doughty, Stefan J CTR (US)" wrote: > I’ve been tasked to get a Certificate of Networthiness (CON) from the U.S. > government so we can use Apache Subversion for version control. I’ve been > using it for several years at home and I love it. > > 1. Is there perhaps a CON already? I’ve looked and saw an older one for > Collabnet Subversion. > 2. I’m filling out the form to apply for the CON, and I need a phone > number and an address. Is that possible? Hello, I'm not familiar with certificates of networthiness or other government requirements for software use. Do they only cover a specific version of the software? If so, and if the one you have is for an older version than the one you want to use, can you cite it in your request for an updated CON? A Google search found this message about a CON having been obtained by the Army for Apache HTTPD Server 2.2.x: https://groups.google.com/forum/?fromgroups#!msg/mil-oss/8SSDWbuUbY4/enkC_MYVRw0J Since version 1.7.0, Subversion is also part of the Apache Foundation, so perhaps it will help you to know that another Apache project has already been approved. I'm not aware of a phone number for the Apache Foundation, but there is a central address: http://www.apache.org/foundation/contact.html Writing to the Legal Affairs Committee's mailing list might be fruitful: http://www.apache.org/legal/
