Re: UNS: Re: svnmucc
On Nov 18, 2013, at 7:33 AM, Andreas Krey a.k...@gmx.de wrote: On Mon, 18 Nov 2013 07:11:40 +, Nico Kadel-Garcia wrote: Brother, unweaving the quotes is its own problem. You see, most filesystems allow single quotes and double quotes in the filenames themselves. Hilarity will ensue. Quoting is a solved problem, including quoting quotes. Using newlines a command argument separator because there may be spaces in files names is a regression from accepted CLI design, and doesn't even solve the problem of newlines in file name which filesystems also allow. Besides, hilarity also ensues there when a file happens to be named 'rm’. svnmucc handles arbitrary long command line arguments with spaces if they are quoted. This is in regards to the -X command line option. Blair
Re: svnmucc
On 11/16/2013 03:06 AM, Andreas Mohr wrote: On Sat, Nov 16, 2013 at 04:29:13AM -0500, Geoff Rowell wrote: On Nov 16, 2013, at 2:10 AM, Vladislav Javadov vapaam...@yandex.ru wrote: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags Each command argument must be on a separate line: rm programs/develop/fasm/tags rm programs/games/mine/tags rm programs/games/snake/tags So, does that mean that svnmucc has single-arg support only? Cause given this example, on the syntax side there's nothing that would indicate that a new command is following, rather than further options to the existing command... (unless rm is one of the commands which are specially recognized as a known-supported command) Sorry for my critique (and thank you for your help!) - just sayin'... Not having looked at the source code, it probably just reads from the file until it reaches the end. The reason to support this syntax with command and arg on separate lines is to support files with whitespaces in the names, which wouldn't be possible wit the syntax of command and arg on a single line. Blair
Re: What FSFS stands for?
On 10/31/2013 08:36 AM, Pavel Lyalyakin wrote: Hello, I see interesting question on StackOverflow: http://stackoverflow.com/q/19687614/761095 [[ I have scoured the internet looking for a clear answer and cannot find one. What does it stand for? I am currently trying to set up a new repo for our development team and I would like to know what this term means. ]] The only answer there states that FSFS stands for File System in File System. Is this correct? Can't find anything on the web or mailing lists on this matter. That's about right: filesystem atop of the filesystem [1] a Filesystem implementation that uses the OS filesystem to store data. [2] [1] http://en.wikipedia.org/wiki/Apache_Subversion#FSFS [2] http://subversion.apache.org/docs/release-notes/1.1.html Blair
Re: Question regarding @ symbol
On 01/08/2013 12:11 PM, Leonard Wayne wrote: Hello. I read the Subversion documentation (in particular the Peg and Operative Revisions section) for how to handle versioning of directories with names that contain the @ symbol. But I am still confused by something. I want to use the import command to import a tree that includes subdirectories with names that contain the @ symbol. For example I would like to do the following (using the Windows syntax): svn import c:\myPath\myDirTree file:///c:/svn/repo/myProject -m Initial import. This will work. The only issue with @ is when it appears in a command line. Anytime you reference one of the directories with a @ in its name, then you'll need to append a @ at the end. The directory tree myDirTree contains subdirectories with names that contain the @ symbol. The command executes without reporting any problems. But is it OK to use this command? Or instead of using the import command should I instead do a bunch of add commands and use the workaround discussed in the Peg and Operative Revisions section of the manual (append @ at the end of the path)? No, just use import. BTW, I don't like import for a different reason is that there's no forgiveness for errors, say if you've left a file in the directory you don't want to import. I like to do a recursive add instead for that reason. Regards, Blair
Re: New to subversion, need to find documentation on writing hooks
On 05/21/2012 03:11 PM, Les Mikesell wrote: On Mon, May 21, 2012 at 4:56 PM, David Weintraubqazw...@gmail.com wrote: Jenkins is pretty simple on the surface to setup. Simply download the Jenkins war file, install a Java JDK if you don't have one installed, and run the following command: $ java -jar jenkins.war Since he mentioned ubuntu earlier, it is probably even easier to go with the packaged version: https://wiki.jenkins-ci.org/display/JENKINS/Installing+Jenkins+on+Ubuntu after which the system will know how to pick up updates. Do you mean apt-get updates or Jenkin's self-provided update mechanism? If the later, is that recommended when it is installed via apt-get? I've always installed Jenkins by hand. Blair
Re: Info about SVN
On 04/17/2012 02:13 PM, Chris Albertson wrote: Other free software you might want to try is CVS and GIT. http://git-scm.com/ http://www.nongnu.org/cvs/ Really, recommending to try CVS??? That's a step backwards ;) Blair
Re: SVN commit behaviour not consistent with other commands (such as delete or add)
On 02/22/2012 02:20 PM, Konstantin Kolinko wrote: 2012/2/23 Evan Weeev...@nationalfibre.net: Strangely, other commands with * used will work, such as svn delete, svn add, etc. Even svn commit * will work somewhat as it commits the modified and added files, but not the deleted ones. I had a discussion with others and their explanation is that the character * refers to valid targets and thus deleted items are not targettable, hence their being missed in the commit. Should this be a valid exception case for svn commit so as to make it consistent with other svn commands? The '*' filename pattern on Unixes is processed by the Shell before the command is passed to Subversion. It matches only existing files. Subversion cannot do anything with it. Officially - see http://pubs.opengroup.org/onlinepubs/009695399/utilities/xcu_chap02.html Shell Command Language - 2.6.6 Pathname Expansion And even if this could be changed, you should just get in the practice of using . as a target instead, as if you do a merge and then 'svn commit *', you won't pick up the property change on the current working directory. In other words, you would have committed everything but the metadata to record the merge. Blair
Re: SVN backup with lvm snapshots and rsync
On 02/15/2012 11:05 AM, Philip Martin wrote: Stefan Sperlings...@elego.de writes: But rather than going through that effort, I would recommend using svnadmin dump/load, or svnsync with file:// URLs, until Subversion 1.8 is released. At which point you can switch over to using svnadmin hotcopy --incremental, which will copy rep-cache.db via the appropriate sqlite APIs. Are you suggesting this because you know the LVM snapshot method doesn't work or just because it's a method that avoids non-standard Subversion tools? Running rsync on an LVM snapshot looks like it should work to me. An LVM snapshot freezes the filesystem by diverting all writes into the snapshot area. A Subversion repository in the frozen filesystem may have transactions in progress, Subversion transactions or SQLite transactions, but they won't change while the copy is made. If the copied repository is ever used then these partial transactions will simply be ignored. Provided Subversion gets its fsyncs and writes in the correct order, and I believe it does, this looks like it should work. I'd go as far as saying if the copied repository doesn't work then this is a Subversion bug, or perhaps an LVM/OS bug. One needs to use at least 1.6.5, there is one fsync I added to ensure that fsfs works without causing empty revprop files. This was seen on a GPFS filesystem [1]. Blair [1] http://subversion.tigris.org/issues/show_bug.cgi?id=3442
Re: multiple svn front-ends, single SAN repo volume
On 2/10/2012 10:21 AM, Bruce Lysik wrote: Hi, I'm considering deploying 3 front-ends, all mounting the same SAN volume for repo. (The SAN handle flock() and fnctl() correctly.) These 3 FEs would be load balanced by a Citrix Netscaler. (At least for http(s).) The largest issues I've run into using a shared storage is not the flock() and fcntl() but the atomic renames. fsfs will atomically rename three files to do a commit and the last rename of the 'current' file, on some shared filesystems, will result in points of time where the systems not doing a commit will not see a 'current' file. If this happens, then any svn read or write operation on the repository will temporarily fail. We had GPFS and it never failed to implement the posix requirements, but it was slow for the number of commits we were pushing (6/sec), so we ended up going to a single server solution with a standby. There was another filesystem, I forgot its name, which didn't implement atomic renames correctly and wasn't usable for svn. Have you tested your SAN deployment? What I would do is create a fsfs repository and on one of your hosts, do as many commits per second as you can in a tight loop, then have another host in a tight loop do an operation on the repository, like get the log message of the HEAD revision. If you want to test your flock() and fcntl() and see how well that performs, try to do as many commits per second into the same repo from two or more hosts. In this case, have a repository with N directories and have each host modify a file in a single directory, that way you won't get any conflicts. How many commits per second are you expecting in practice? Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies bl...@orcaware.com Subversion training, consulting and support http://www.orcaware.com/svn/
Re: Difference between 'svn update' and 'svn checkout'
On 11/11/2011 06:41 PM, Andy Levy wrote: On Fri, Nov 11, 2011 at 21:12, Welington Rodrigues Braga welrbr...@welrbraga.eti.br wrote: Hi guys, I've just started to use Subversion a few months ago and I am really are asking me why I had never used it before but it is not the reason of my contact. To be honest I am trying to to do a post-commit script that automatically sincronizes a given workcopy when any of my users commits their modifications to my repository. Although it's is ok and working fine (at least in my simples test), I did not put in production yet because I have a doubt that neither Subversion manual or Google were able to answer me. I didn't find any difference beetwen 'svn update' and 'svn checkout' commands which is the main function of my post-commit script. Nowadays I'm using 'svn checkout' and it is working, like I said, but I'm not sure if I'm losing some functionality with this option. Can anyone help me and answer my question? svn checkout creates a new working copy. svn update updates an existing working copy. As Andy said, but there is some special behavior in checkout. If you run svn checkout on top of an existing working copy it'll work if the URL is the same as the working copy URLs, but otherwise fail, so this may explain the behavior you see. But if you did svn co $URL1 dir svn co $URL2 dir the second one would fail. It's best to do something like this if test -d dir; then svn up dir else svn co $URL dir fi
Re: Difference between 'svn update' and 'svn checkout'
On Nov 11, 2011, at 7:17 PM, Welington Rodrigues Braga wrote: 2011/11/12 Blair Zajac bl...@orcaware.com: On 11/11/2011 06:41 PM, Andy Levy wrote: On Fri, Nov 11, 2011 at 21:12, Welington Rodrigues Braga welrbr...@welrbraga.eti.br wrote: Hi guys, I've just started to use Subversion a few months ago and I am really are asking me why I had never used it before but it is not the reason of my contact. To be honest I am trying to to do a post-commit script that automatically sincronizes a given workcopy when any of my users commits their modifications to my repository. Although it's is ok and working fine (at least in my simples test), I did not put in production yet because I have a doubt that neither Subversion manual or Google were able to answer me. I didn't find any difference beetwen 'svn update' and 'svn checkout' commands which is the main function of my post-commit script. Nowadays I'm using 'svn checkout' and it is working, like I said, but I'm not sure if I'm losing some functionality with this option. Can anyone help me and answer my question? svn checkout creates a new working copy. svn update updates an existing working copy. As Andy said, but there is some special behavior in checkout. If you run svn checkout on top of an existing working copy it'll work if the URL is the same as the working copy URLs, but otherwise fail, so this may explain the behavior you see. But if you did svn co $URL1 dir svn co $URL2 dir the second one would fail. It's best to do something like this if test -d dir; then svn up dir else svn co $URL dir fi Thanks Andy and Blair. I've already understood this part explained on manual so my doubt is considering that a working copy was created and populated before, it will only receive changes (never it will send or commit them) and aI will not modify he URL. Considering those points. Will the behavious of both be the same or there are any risk of happen something wrong? Yes, generally, there is no subcommand in the Subversion command line client that pulls and pushes data to the Subversion server, all commands are one way for updates, the either update the data in the working copy or the data in the repository. So you have nothing to worry about inadvertently pushing data to the repository with a update or checkout. Regards, Blair
Re: Problems compiling 1.7.0 on redhat el4 64bit
On Aug 11, 2011, at 8:32 AM, michael_rytt...@agilent.com michael_rytt...@agilent.com wrote: No luck with that option, still crashing. Try running the process under valgrind to see if it finds anything. Blair
Re: Generating SVN libraries from source on Mac OSX
On May 20, 2011, at 3:40 AM, Ian Sidor wrote: Oops. Thank-you for pointing that out, my mistake. However, I still cannot find any libsvn*.a files anywhere on the drive. As described in my first mail, there is a file I can see with the extension 'LA' which is a text file. It states that the libraries will be built to /usr/local/lib but they don't seem to be there after I execute make. You have to run make install to get them to install into /usr/local/lib. BTW, if you're building libraries for your application, it's probably best to pick a different directory than /usr/local, since it's a common dumping ground. Choose something like /opt/my_company_name/product_name. Also, you could build with MacPorts into /opt/my_company_name/product_name and then have it provide all the .a's. Blair
Re: Generating SVN libraries from source on Mac OSX
Static libraries end in .a, not .dylib, those are shared. Blair On May 19, 2011, at 9:23 AM, Ian Sidor wrote: I tried --disable-shared but I still didn't get any libsvn*.dylib files. Is there anything else I can try? On 19 May 2011, at 07:47, Daniel Shahaf wrote: Just ignore the file you don't need then? Or try --disable-shared Ian Sidor wrote on Thu, May 19, 2011 at 00:00:45 +0100: I'm building Subversion from source in order to generate static libraries to use in my own application. I can build Subversion fine but I don't seem to be getting any libraries (dylib's). Here is what I type in terminal: curl -O http://subversion.tigris.org/downloads/subversion-1.6.16.tar.gz curl -O http://subversion.tigris.org/downloads/subversion-deps-1.6.16.tar.gz tar xzvf subversion-1.6.16.tar.gz tar xzvf subversion-deps-1.6.16.tar.gz ./configure --enable-static make I found a file 'libsvn_client-1.la' which is required for linking. The text inside describes 'libsvn_client-1.dylib' but it is never generated after make is executed. I've tried everything I can think of no doubt missing something simple, I'm not too familiar with Unix open source conventions. Can someone help me with this please? Thank-you. Ian.
Re: repo on Windows -- why not?
On 4/28/11 9:42 AM, Danil Shopyrin wrote: are there any arguments to prefer Windows? (beside arguments that you drive a Windows shop) ok, looks like I have to adjust the section a bit. It's also very important to integrate Subversion seamlessly with Active Directory and other existing Windows infrastructure (it applies to Windows shops, of course). Just to add a bit to this, if one has Active Directory but uses Unix servers, one doesn't have to deploy on Windows to authenticate, can use LDAP in httpd to authenticate against AD. Blair
Re: ^M Appends to every line?
On 2/24/2011 8:02 AM, Christopher D Haakinson wrote: OK, so I've been testing out the svn:eol-style prop and it appears to work, but it seems like an awful lot of work for such a simple issue. Is there something server-side I can setup to ensure that all files contain the correct eol style? As others have said, you can use a pre-commit script to check the files. If you have a number of files already checked in that you want to update their properties, you can use the svn_apply_autoprops.py script that I wrote a while back on a working copy to fix up everything in one commit: http://svn.apache.org/repos/asf/subversion/trunk/contrib/client-side/svn_apply_autoprops.py Regards, Blair
Re: svn update or rsync - which is best to update live files
On 2/25/11 11:39 AM, Christopher D Haakinson wrote: Hi, I have subversion up and running quite well now(thanks to everyone here :-)) Now I've come to the point in my development where I need to figure out what's the best method for transferring my svn files to my live site. I've read that I should use a post-commit hook, which is fine I'm using a pre-commit hook already so I'm aware of how they work. My main question is: Which method is best for updating my live files? Should I use rsync in my post hook or should I use svn update? http://subversion.apache.org/faq.html#website-auto-update this page recommends using svn update, but I wanted to get some input from the community too. Thanks in advance! First, both svn and rsync do atomic replaces of the file, so you don't have to worry about the live files being observed in some odd state. There are tradeoffs. - rsync will need to stat() each file in your working copy - svn will only update the files that are newer; however - svn currently requires a lock on each subdirectory rsync will have two times the stat()'s, one for the source and one for the destination. Probably for speed, your best bet is to time either. In 1.7, I would definitely use svn, as the locking issue goes away. Blair
Re: internal dirs showing up on update
On 2/17/11 12:50 PM, Bob Archer wrote: I have so SVN repos (subversion) and I use them with no proble. But when we do updates/commints on client (tortoise) we always get teh internal directories: conf dav db hooks locks format README.txt These es are internal and should not appear right? How do I remove this? I assume these folder are in your repository. Just go into the repository browser in TortoiseSVn and delete the folders. It sounds like somebody checked in a copy of a repo into the repo, in which case it's safe to delete. Blair
Re: Could not read status line: connection was closed by server
On 1/21/2011 7:42 PM, 刘斌 wrote: Hello everyone I am seeing a odd problem. one of my developers on windows 2003,running the CollabNet-supported Subversion 1.6.15 binaries, does this command: svn commit following this error: Could not read status line: connection was closed by server on the svn server, there is nothing in the apache log. but on the same machine, I open the Subversion repo browser, then create folder\add files which all can be successful. what's the possible reason?do you give me any advises, thank you! How are you connecting to the server, file:///, http://, https://, svn://, svn+ssh://? If you're using http://, then try using https://. If the later works, then there's something in the network that's affecting the traffic. Regards, Blair
Re: 207 Multi-Status error checking out WebKit repository on Windows
On 1/6/11 10:30 AM, Kenneth Russell wrote: On Tue, Jan 4, 2011 at 5:29 PM, Blair Zajacbl...@orcaware.com wrote: On 12/25/10 5:42 PM, Kenneth Russell wrote: Hello, The WebKit project uses Subversion for version control and we are facing a problem with fresh checkouts of the repository on Windows with Subversion 1.6.6 (as well as earlier versions -- I've also tried 1.6.1). The reported error is with a specific file: svn: PROPFIND of '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js': 207 Multi-Status (http://svn.webkit.org) The WebKit project maintainers aren't sure what changed with this particular file to cause this error to start occurring. I was only able to get past it by copying the .svn directory for this subdirectory from another Windows machine (where the checkout predated the problematic changes to this file) and then continuing the checkout. Is this a known issue? Can you reproduce it by checking out the repository (see http://webkit.org/building/checkout.html) with the current (non-Cygwin) Subversion binaries? If you try with an https URL, do you see the same issue? That will avoid any networking issues you may be running into. https://svn.webkit.org/repository/webkit/trunk Thanks for the suggestion. I was able to successfully check out the WebKit repository on Windows with Subversion 1.6.6 from the https URL. I haven't yet re-tried checking out from the http URL to confirm the 207 Multi-Status error was 100% reproducible on this machine. Ken, That's great. Sounds like a proxy may be getting in the way. BTW, some Googler's do work on svn, such as the Google Code people, if you ever need help :) Regards, Blair
Re: 207 Multi-Status error checking out WebKit repository on Windows
On 12/25/10 5:42 PM, Kenneth Russell wrote: Hello, The WebKit project uses Subversion for version control and we are facing a problem with fresh checkouts of the repository on Windows with Subversion 1.6.6 (as well as earlier versions -- I've also tried 1.6.1). The reported error is with a specific file: svn: PROPFIND of '/repository/webkit/!svn/bc/19963/trunk/LayoutTests/fast/xpath/4XPath/Core/test.js': 207 Multi-Status (http://svn.webkit.org) The WebKit project maintainers aren't sure what changed with this particular file to cause this error to start occurring. I was only able to get past it by copying the .svn directory for this subdirectory from another Windows machine (where the checkout predated the problematic changes to this file) and then continuing the checkout. Is this a known issue? Can you reproduce it by checking out the repository (see http://webkit.org/building/checkout.html) with the current (non-Cygwin) Subversion binaries? If you try with an https URL, do you see the same issue? That will avoid any networking issues you may be running into. https://svn.webkit.org/repository/webkit/trunk Regards, Blair
Re: can i svn cat without keyword expansion
On Aug 8, 2010, at 8:50 AM, Nico Kadel-Garcia wrote: On Sat, Aug 7, 2010 at 9:21 PM, Blair Zajac bl...@orcaware.com wrote: On Aug 6, 2010, at 3:16 PM, Bob wrote: Hi, If I do svn cat on a file, with the svn:keywords property set, it expands out SVN keywords such as $Date$, $Revision$, $Id$, etc., in the file (the ones there were included in the svn:keywords property anyway). Is there an option that will NOT do the expansion? Or is there some other way of using the svn client that will achieve the same thing? As I understand, the file is stored in the repository with keywords not expanded, and the client expands them when it retrieves them, so shouldn't it be trivial to have a functionality to skip this step? Thanks, Do you want to do this for all files in a checkout or just get a file? If the later, you can use curl or wget if you're using http:// or https:// scheme. The original poster in this thread asked about using svn cat and disabling the keywords: quite sensible, really. Who said anything about not providing this feature? I would find it useful when I do diffs also. This was just a workaround if you needed a single file without keywords. For a trees worth, of course, it would be painful to script to do a checkout without keyword expansion. Blair
Re: can i svn cat without keyword expansion
On Aug 6, 2010, at 3:16 PM, Bob wrote: Hi, If I do svn cat on a file, with the svn:keywords property set, it expands out SVN keywords such as $Date$, $Revision$, $Id$, etc., in the file (the ones there were included in the svn:keywords property anyway). Is there an option that will NOT do the expansion? Or is there some other way of using the svn client that will achieve the same thing? As I understand, the file is stored in the repository with keywords not expanded, and the client expands them when it retrieves them, so shouldn't it be trivial to have a functionality to skip this step? Thanks, Do you want to do this for all files in a checkout or just get a file? If the later, you can use curl or wget if you're using http:// or https:// scheme. Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies bl...@orcaware.com Subversion training, consulting and support http://www.orcaware.com/svn/
Re: Support for filesystem snapshots (?)
On 08/02/2010 01:27 PM, Stefan Sperling wrote: On Mon, Aug 02, 2010 at 03:25:48PM -0400, Vallon, Justin wrote: E.g. Subversion's FSFS needs to create a revision file from the commit's transaction, and move the finalized revision file into place. After the revision file has been moved into place successfully, FSFS also updates the svn:date revision property and moves the revision properties file into place (or copies revprop data into an sqlite database if you use revprop packing). Then, it updates the 'current' file which contains the number of the current HEAD revision. If you use representation sharing to save disk space, the commit may involve further updates to yet another sqlite database. All these actions need to complete in order to have a consistent state. If you're interested in seeing the code that does this, look at the svn_fs_fs__commit() and commit_body() functions in http://svn.apache.org/repos/asf/subversion/trunk/subversion/libsvn_fs_fs/fs_fs.c I see this is executed with a FS write lock. My concern would be focused on the interaction between the commit code and any rollback code. For example, if the commit dies (any any point during the commit), what will be required to insure that the repository behaves as if the commit never started? Will a repo cleanup be required; will the next committer cleanup the partial rev automatically (ie: overwrite stale files); will the repo be hopelessly inconsistent? I honestly didn't know so I went and asked. And learned something! stsp users asking interesting questions: http://mail-archives.apache.org/mod_mbox/subversion-users/201008.mbox/%3c6ec02a00cc9f684daf4af4084ca84d5f01c40...@drmbx3.winmail.deshaw.com%3e stsp i dunno how fsfs behaves in face of an interrupted commit; whether or not it needs to be rolled back danielsh if you haven't touched current than the rev file will never be read and will be overwritten danielsh stsp: does that answer your question? stsp i think so stsp because the rev file of the following commit will have the same name to move things into place onto danielsh write lock only for revprop change and commit danielsh :-) stsp so, using rsync for backup is fine? danielsh if you copy current first, yes stsp what's hotcopy for then? just bdb? ehu stsp: copying 'current' first ... :-) stsp ok, so what happens if I don't copy current first? danielsh you can copy revs/ danielsh then a commit happens danielsh then you copy current danielsh so you don't have all of revs/ that current claims exist stsp then I need to unwedge it stsp by decrementing current danielsh right danielsh and hopefully you haven't just crossed a packing boundary danielsh eg if you want to decrement from 1002 to 999 danielsh and someone packed it already danielsh a bit more work So in the event that 'current' says you are at rN but the rev data in the repository is still at r'N-1', the repository will complain (I've tried that, No such revision rN), and you'll need to decrement the counter in 'current'. But otherwise, the repository will continue to work. Now, how does rsync, or a file-system snapshot, know to make sure that 'current' is always copied first? Even if you copy 'current' first manually, rsync might later overwrite it. But unless you use packing it's trivial to fix the backup if it breaks, and all you risk is losing the most recent HEAD revision, which you may not have gotten with a hotcopy anyway. Still, I think I'll keep advising people to use hotcopy. It avoids the problem with a too recent 'current' file, i.e. the backup is always usable out of the box. And who knows how Subversion's on-disk formats will at change in the future. The hotcopy approach will always be supported, and works fine if, as you pointed out, you can make sure that a hotcopy is being backup up while not being written to. There's this tool that should order rsync correctly: http://svn.apache.org/repos/asf/subversion/trunk/contrib/server-side/svn-fast-backup But in general, you're correct, with the additions to the fsfs repository, this script is not always kept up to date. Blair
Re: Is contrib status changing with apache move?
On Jul 23, 2010, at 5:55 AM, David Weintraub wrote: On Thu, Jul 22, 2010 at 6:25 PM, Joe Briggs jbri...@primetherapeutics.com wrote: I am not sure if it is kosher to ask about contribs on the list, but fools rush in... [...] My larger question is about contribs in general now that the project has moved to apache. The vendor branch management strategy in the svn book still refers to svn_load_dirs.pl, but it is rarely included by those folks creating binaries for windows. (I am not sure about packagers for other platforms). Is there a thought about whether contribs will be left behind, or rolled in more? I wrote the list a few weeks ago about adding some new pre-commit hooks into Subversion, and the reply was that the Subversion project is no longer maintaining contributed software which would include hooks. The contributed software wasn't ever officially maintained, just interested developers would own files in there. I found the script over at Fresh Ports http://www.freshports.org/devel/svn_load_dirs/. It looks like someone over there is actively maintaining it. I think this is just pulling the files from the tarball, so it's not active development of the script itself. If you send in patches to it, then somebody may apply them to the source. Regards, Blair
Re: Unclear syntax for relative addressing of svn:externals, on RHEL 5, subversion-1.6.12
On 07/13/2010 05:15 AM, Stefan Sperling wrote: On Mon, Jul 12, 2010 at 05:57:24PM -0400, Nico Kadel-Garcia wrote: I don't know why the syntax was reversed: it really looks like an entirely unnecessary parsing complication. The new syntax looks more like 'svn checkout', so it's more natural to use when you're already used to svn checkout. I would change it like this: I think we should discourage use of the old syntax in both the output of svn help and in the book. Diff to the help text below. Would this improve things? Sounds good to me. I think this last sentence starting with The ambiguous format... should go before 1.4 is mentioned because it is relevant to the 1.5 format. Blair
Re: svnadmin load to fsfs 9 times faster than bdb!?
On 05/31/2010 11:06 AM, B Smith-Mannschott wrote: On Mon, May 31, 2010 at 02:52, Mark Phippardmarkp...@gmail.com wrote: You just need to specify --bdb-txn-nosync when running svnadmin create. although it is possible that svnadmin load also accepts this option. This should make the load times about the same. There is something you are supposed to change after loading the dumpfile to turn this back on. Yup, by creating the repository with --bdb-txn-nosync the time to load the dump was reduced to about 9 hours (less than double the time of FSFS). db/DB_CONFIG is the place to go to get the safer behavior back once the load has completed: set_flags DB_TXN_NOSYNC After changing any of the flags in DB_CONFIG you need to recover the database using svnadmin recover. Blair
Re: What file system structure a SVN transaction follow ?
On 4/30/10 4:15 AM, Ravi Roy wrote: Not really sure. making a file *svnlook cat* will definitely slow down operations (specially for big files). But anyway file has to be transferred to server before transaction size could be computed. So until commit is taking place, it would not be part of repo. Does somebody knows an optimum way how this could be achieved without causing performance bottlenecks? If you use the SWIG bindings and the svn_fs API directly, then you can use svn_fs_file_length() to get the length of the file without catting it. Here's the API that the bindings are build from: http://svn.apache.org/repos/asf/subversion/trunk/subversion/include/svn_fs.h Regards, Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies bl...@orcaware.com Subversion training, consulting and support http://www.orcaware.com/svn/
Re: Can we use relative paths in svn:externals propset?
On 04/29/2010 01:09 PM, David Bartmess wrote: I have two projects under a single repository, with A being dependent on B being checked out. To set the svn:externals propset, can I use a relative path for the checkout directory for the depending (B) directory? Such as : svn propset svn:externals ../buildsupport http://URL/buildsupport/trunk BuildScripts Will this work? I can't afford to try it on that repository since it's a live development repository... You can always try setting up externals by modifying them in your working copy and running svn update and see if you get the desired result. You don't need to commit the change to test it. IIRC, you can't have a relative path to a directory outside the directory where the external is, as it doesn't know if it's a Subversion working copy or not. Blair
Re: Common name for transaction and revision object
On 4/28/10 6:46 AM, Giulio Troccoli wrote: Linedata Services (UK) Ltd Registered Office: Bishopsgate Court, 4-12 Norton Folgate, London, E1 6DB Registered in England and Wales No 3027851VAT Reg No 778499447 -Original Message- From: Geoff Rowell [mailto:geoff.row...@gmail.com] Sent: 22 April 2010 14:21 To: Giulio Troccoli Cc: users@subversion.apache.org Subject: RE: Common name for transaction and revision object Giulio Troccoligiulio.trocc...@uk.linedata.com wrote: I'm writing the hooks for a new repository in Perl and I'm exploring using OO Perl. In both pre- and post-commit hooks I need the list of files, the author and other similar information. My idea was to define a class and create an instance of that class given either the transaction number adn repository path or the revision number and the repository URL. The 'new' function will then initialise all the information I need calling either svnlook or svn. For instance: As you can see they are almost the same, so it would be nice to have a single class (I could then check the second parameter to see if it's a URL or a path and do things accordingly). But I cannot come up with a single name that would encompass both, and that's what I'm asking the list. So, any suggestions? Sorry, for posting again but I haven't received any suggestions regarding the name. Nobody can come up with anything? Really? If you look at the svn_fs.h API, they are both referred to as revision roots. svn_fs_revision_root() and svn_fs_txn_root() both return a svn_fs_root_t * object. Blair
Re: Common name for transaction and revision object
On 04/28/2010 02:38 PM, Ryan Schmidt wrote: On Apr 28, 2010, at 10:03, Blair Zajac wrote: If you look at the svn_fs.h API, they are both referred to as revision roots. svn_fs_revision_root() and svn_fs_txn_root() both return a svn_fs_root_t * object. That does not sound like they're both being referred to as revision roots; that sounds like they're both being referred to as roots. Oops, yes, they are filesystem roots. If you're just looking to name a variable, you can call it RevisionOrTransaction. I've done that in code I've used, or RevisionOrTransactionRoot for my use case. Blair
Re: windows vs unix question
On 02/01/2010 12:19 PM, Andy Levy wrote: On Mon, Feb 1, 2010 at 15:14, Robert Nursernu...@gmail.com wrote: Is anyone familiar with the SVN client in Dreamweaver CS4? Development is performed on Windows boxes. But, the server is on a Sun box. All Subversion servers and clients with the same major revision number (1.x.) are compatible thanks to the Remote Access (RA) layer. Depending on the specific versions being used at each end, some features may be disabled but the basics are there. I'm not able to find anything online which indicates *which* release of Subversion CS4 has built into it. As I recall it's a 1.4.x release. Blair
Re: Version of a single file
deostroll wrote: Is it possible to get the version of a single file inside a repo? What do you mean by version? You can use svn info on a URL to the file. Blair -- Blair Zajac, Ph.D. CTO, OrcaWare Technologies bl...@orcaware.com Subversion training, consulting and support http://www.orcaware.com/svn/
