does "svn diff" has a bug for external items ?
Hello, I'm wondering whether this bug https://bugs.gentoo.org/show_bug.cgi?id=309183 is Gentoo specific or worth to be filed in svn bug tracking system too. -- MfG/Sincerely Toralf Förster pgp finger print: 7B1A 07F4 EC82 0F90 D4C2 8936 872A E508 7DB6 9DA3
Re: fixing bug in multiple releases
Hi, Thanks Andy and David for your answers. As I said, it was just a supposition in a case where it becomes necessary to fix all previous releases (for whatever reason). And in this case, I too think not to touch the tag itself rather as per David's advise, branch the tag 1.6, fix it and then release it as 1.6.1 tag. However, in my case, its a typical web application providing online payment services to web users. Where, the chances of deploying previous releases are very less. Because the advancement goes on with the new features adding in site and making it more productive. *David says: > * *That said, let's say you're working on REL-1.7, but it isn't ready, and a > bad bug was found in REL-1.6. You should copy the tag REL-1.6 to a branch, > fix the bug on the branch, and then create a new REL-1.6.1 tag. That way, > you can see that you had a REL-1.6 and what changes you had to make to get > to REL-1.6.1. If you change the tag, you lose this information. Plus, you > end up with two REL-1.6s: One with the patch and one without. How are you > going to know the difference between the two REL-1.6.* > In this case, how I will update the bug fix in REL-1.7 which I fixed in 1.6.1 tag ? Is it the developer's responsibility to redo the bug fixing steps on REL-1.7 which he did in REL1.6 ? Or is there any automated process provided by SVN ? Because latest development is going on REL-1.7 which do posses the bug of REL1.6. Also, in case of web-applications what is the best practice to deploy REL-1.7 on production ? Do we replace whole REL-1.6 code with REL-1.7 or just update the production with modified binaries of REL1.7 ? Bye, Viki, On Mon, Apr 19, 2010 at 10:46 PM, David Weintraub wrote: > On Mon, Apr 19, 2010 at 3:14 PM, Vikrama Sanjeeva > wrote: > >> Suppose I have total 6 releases in /tag which are considered as stable >> releases. Now if, at 6th release we realize that there is a "bug" which >> should be fixed in all previous releases then what should be the strategy ? >> Is there any way in SVN which allows to fix bug in all releases "at-a-time" >> ? >> > > > Our strategy is to never change a tag and that goes double for "release" > tags. > > Releases should be hierarchical in nature. That is, REL-1.1 contains all > the stuff in REL-1.0 and additional bug fixes and features. If you have > someone in REL-1.0, and they want a bug fixed that is fixed in REL-1.1, they > should be upgraded to REL-1.1 and not have REL-1.0 patched. > > Of course, there are exceptions to this rule, but you have to balance the > number of versions of software you're maintaining with the number of > releases you can track and maintain. Having each customer with a unique > release would be bad management of your time and resources. > > So, the question is what are these six releases. If they're REL-1.0 through > REL-1.6, you probably don't need to fix REL-1.0 through REL-1.5. Instead, > you should create a REL-1.7 with the fix and upgrade everyone to that. > Again, there are reasons why this might not be possible, but the ideal is to > be able to keep yourself on as few releases as possible that you have to > maintain. > > That said, let's say you're working on REL-1.7, but it isn't ready, and a > bad bug was found in REL-1.6. You should copy the tag REL-1.6 to a branch, > fix the bug on the branch, and then create a new REL-1.6.1 tag. That way, > you can see that you had a REL-1.6 and what changes you had to make to get > to REL-1.6.1. If you change the tag, you lose this information. Plus, you > end up with two REL-1.6s: One with the patch and one without. How are you > going to know the difference between the two REL-1.6. > > The way I do releases is always doing a release off a branch. Branches > diverge in my scheme, that is the trunk and the branch diverge over time. > > For example, we get to a point where all the features in REL-1.6 are pretty > much complete. We'll now be spending time patching bugs and optimizing the > code. At this point, I create a 1.6 branch: > > $ svn cp http://path/to/project/trunk http://path/to/project/branches/1.6 > > This allows most of my developers to continue working on the next release > while the few developers involved in getting REL-1.6 out the door will work > off the branch. > > When we're ready to release, we tag the branch: > > $ svn cp http://path/to/project/branches/1.6 > http://path/to/project/tags/REL-1.6 > > If we find a bug in REL-1.6, we can continue doing our work off the 1.6 > branch, and fix the bug on that branch. Once we've finished, we can tag that > work: > > $ svn cp http://path/to/project/branches/1.6 > http://path/to/project/tags/REL-1.6.1 > > When we're about to do REL-1.7, I'll again branch from trunk to a 1.7 > branch and we go on from there. > > So, to answer your question: > > * Should you update all of your tags? No, you shouldn't ever move a tag. > Instead, create a branch you can work off of from the tag (if necessary), > fix your bugs on the
entries.c line 2715: assertion failed (orig_schedule == entry->schedule)
Hi, I got an exception from TortoiseSNV 1.6.8 : --- Subversion Exception! --- Subversion hat ein ernstes Problem festgestellt. Bitte nehmen Sie sich die Zeit, es mit einer möglichst ausführlichen Beschreibung, was sie zu tun versuchten, an die Subversion Mailingliste weiterzuleiten. (users@subversion.apache.org) Bitte durchsuchen Sie zuerst das Listenarchiv nach der Fehlermeldung, um doppelte Berichte zu vermeiden.Das Listenarchiv finden Sie unter http://subversion.apache.org/mailing-lists.html Subversion berichtet folgendes: In Datei »D:\Development\SVN\Releases\TortoiseSVN-1.6.8\ext\subversion\subversion\libsvn_wc\entries.c«, Zeile 2715: Assert-Anweisung schlug fehl (orig_schedule == entry->schedule) --- OK --- In the commit dialog, I selected a new folder and a file in this folder to add it to the repository. I had problems before with this folder, sometimes it disappeared from the repository. So I deleted the folder (that worked) and now tried to add it again. I think there's someting wrong with the repository or thw working copy, but how can I find the reason? I'm not familiar with SVN's internal data structures. A cleanup didn't show or fix the problem. Regards, Jürgen
hook-script doesn't run in background
Hi, I need to run an ant script after a commit, so I used a post-commit script for that. However, even if I put the ant call into the background and redirect stdout and stderr, it still returns only after the ant call is done. I found an old discussion about this (http://svn.haxx.se/dev/archive-2006-01/0375.shtml), is there still no workaround or fix? This is the relevant part of the script (commenting it out fastens it): ant all -f MDM-Leitfaden/ant_scripts/mdm-leitfaden.xml > /tmp/dita.log 2>&1 Lars (not subscribed, so a CC to mail would be nice)
RE: hook-script doesn't run in background
> I need to run an ant script after a commit, so I used a > post-commit script for that. However, even if I put the ant > call into the background and redirect stdout and stderr, it > still returns only after the ant call is done. I found an old > discussion about this > (http://svn.haxx.se/dev/archive-2006-01/0375.shtml), is there > still no workaround or fix? > This is the relevant part of the script (commenting it out > fastens it): > > ant all -f MDM-Leitfaden/ant_scripts/mdm-leitfaden.xml > > /tmp/dita.log 2>&1 > It looks like your post-commit hooks is a ksh, so have you tried adding & at the end? Like ant all -f MDM-Leitfaden/ant_scripts/mdm-leitfaden.xml > /tmp/dita.log 2>&1 & G 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
Re: hook-script doesn't run in background
2010/4/21 Giulio Troccoli : > It looks like your post-commit hooks is a ksh, so have you tried adding & at > the end? Like > > ant all -f MDM-Leitfaden/ant_scripts/mdm-leitfaden.xml > /tmp/dita.log 2>&1 & great! though my fist line is #!/bin/bash, but of course I forgot that additional "&" for putting it into background. First I had only the & in the end for background, but obviously stderr/stdout were kept open then. So redirecting stderr/stdout AND putting it into the background works thanks, Lars
Recursive setting of versioned properties using URL using propedit or svnmucc
Hi, I'm trying to write a skript to set versioned properties after been triggered by a hook but I seem to get stuck finding a solution and hope someone here is able to help me or point out if it's not possible. I'd like to set a property for every file in a certain directory(recursivly) using an url. Something like svn propedit -R PROPNAME PROPVAL URL or svnmucc propset PROPNAME PROPVAL -R URL My problem is that propedit doesn't support recursivly setting of properties and svnmucc gives an error( 'file already exists') when been used on a file. I'd also be glad if someone had a link to a kind of documentation for svnmucc which I haven't been able to find till now because I would like to avoid raising the revision number for each file/dir. Kind regard Bettual
Re: does "svn diff" has a bug for external items ?
2010/4/21 Toralf Förster : > Hello, > > I'm wondering whether this bug http://bugs.gentoo.org/show_bug.cgi?id=309183 > is Gentoo specific or worth to be filed in svn bug tracking system too. This was reported back in March and the last post on the subject (mine) was that the error could not be reproduced with the same release of Subversion on MacOS X. http://svn.haxx.se/users/archive-2010-03/0362.shtml Which points at an issue in Gentoo's packaging of Subversion or one of the dependent packages.
Re: svn: invalid parameter supplied
On 4/20/2010 9:09 AM, Andy Levy wrote: On Tue, Apr 20, 2010 at 09:57, Marvin Solomon wrote: I have a repository with svnserver running on Linux and am trying to set up a client on Windows. ... There's really no compelling reason to use the cygwin Subversion client for the majority of users. Try the native Win32 version. Make sure you've got a version which matches your TSVN version. Thanks for the workaround. The cygwin svn is broken, but the native svn seems to work fine. This is definitely a bug and should probably be reported, but I'm not sure where. Any suggestions? Here's some more info. The windows platform is Windows 7. BTW, what's TSVN? --- windows> uname -a CYGWIN_NT-6.1 MSOLOMONLT01 1.7.5(0.225/5/3) 2010-04-12 19:07 i686 Cygwin windows> /bin/svn update Makefile svn: invalid parameter supplied windows> /bin/svn --version svn, version 1.6.9 (r901367) compiled Feb 10 2010, 10:34:02 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme windows> C:/PROGRA~1/COLLAB~1/SUBVER~1/svn update Makefile At revision 31105. windows> C:/PROGRA~1/COLLAB~1/SUBVER~1/svn --version svn, version 1.6.9 (r901367) compiled Jan 21 2010, 22:00:47 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme --- linux> Linux csi 2.6.9-78.0.17.ELsmp #1 SMP Thu Mar 5 04:58:34 EST 2009 x86_64 x86_64 x86_64 GNU/Linux linux> svn --version svn, version 1.6.9 (r901367) compiled Jan 24 2010, 10:18:33 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository access (RA) modules are available: * ra_neon : Module for accessing a repository via WebDAV protocol using Neon. - handles 'http' scheme - handles 'https' scheme * ra_svn : Module for accessing a repository using the svn network protocol. - with Cyrus SASL authentication - handles 'svn' scheme * ra_local : Module for accessing a repository on local disk. - handles 'file' scheme * ra_serf : Module for accessing a repository via WebDAV protocol using serf. - handles 'http' scheme - handles 'https' scheme linux> svnserve --version svnserve, version 1.6.9 (r901367) compiled Jan 24 2010, 10:18:33 Copyright (C) 2000-2009 CollabNet. Subversion is open source software, see http://subversion.tigris.org/ This product includes software developed by CollabNet (http://www.Collab.Net/). The following repository back-end (FS) modules are available: * fs_fs : Module for working with a plain file (FSFS) repository. Cyrus SASL authentication is available. ---
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
Bettual Richter wrote: >I'm trying to write a skript to set versioned properties after been >triggered by a >hook but I seem to get stuck finding a solution and hope someone here >is able to help me or point out if it's not possible. > >I'd like to set a property for every file in a certain >directory(recursivly) using >an url. Something like > >svn propedit -R PROPNAME PROPVAL URL I think you meant propset but anyhow svn prop* for versioned properties only work in on a working copy. the remote version only works for revision properties >or > >svnmucc propset PROPNAME PROPVAL -R URL svnmucc has no -R option. >My problem is that propedit doesn't support recursivly setting of >properties and svnmucc gives an error( 'file already exists') when been >used on a file. >I'd also be glad if someone had a link to a kind of documentation for >svnmucc which I haven't been able to find till now because I would like >to avoid raising the revision number for each file/dir. you either need to checkout to a temporary working copy apply the properties and commit, or generate a file containing one 'propset PROPNAME VAL URL' command per line for each file/folder you want to modify. Then call svnmucc with '--extra-args FILENAME' -- Lorenz
Re: fixing bug in multiple releases
Vikrama Sanjeeva wrote: Also, in case of web-applications what is the best practice to deploy REL-1.7 on production ? Do we replace whole REL-1.6 code with REL-1.7 or just update the production with modified binaries of REL1.7 ? Normally you would want to work in a way that gives you a known 'roll-back' state in case the next change introduces problems. If you don't keep a whole release together you'll have to track the individual changes to know how to reproduce the last working state. -- Les Mikesell lesmikes...@gmail.com
Re: svn: invalid parameter supplied
On Wed, Apr 21, 2010 at 07:41, Marvin Solomon wrote: > > > On 4/20/2010 9:09 AM, Andy Levy wrote: >> >> On Tue, Apr 20, 2010 at 09:57, Marvin Solomon >> wrote: >>> >>> I have a repository with svnserver running on Linux and am trying to set >>> up >>> a client on Windows. ... >> >> There's really no compelling reason to use the cygwin Subversion >> client for the majority of users. Try the native Win32 version. Make >> sure you've got a version which matches your TSVN version. > > Thanks for the workaround. The cygwin svn is broken, but the native svn > seems to work fine. This is definitely a bug and should probably be > reported, but I'm not sure where. Any suggestions? Here's some more info. > The windows platform is Windows 7. I'd suggest reporting it to whomever built the cygwin version you're using. Cygwin is a really strange thing. It pretends it's *NIX and makes programs that are running on Windows think they're running on *NIX, so they try to do *NIX-y things, but they fail because at the bottom of the stack, it's still Windows. If you can at all avoid using Cygwin, do so. Many of the GNU command-line programs (grep, sed, awk, wc, more, et. al.) have been ported to native Win32 and work great. > BTW, what's TSVN? TortoiseSVN
Re: fixing bug in multiple releases
On Wed, Apr 21, 2010 at 3:42 PM, Les Mikesell wrote: > Vikrama Sanjeeva wrote: > >> >> Also, in case of web-applications what is the best practice to deploy >> REL-1.7 on production ? Do we replace whole REL-1.6 code with REL-1.7 or >> just update the production with modified binaries of REL1.7 ? >> > > Normally you would want to work in a way that gives you a known 'roll-back' > state in case the next change introduces problems. If you don't keep a > whole release together you'll have to track the individual changes to know > how to reproduce the last working state. > > -- > Les Mikesell > lesmikes...@gmail.com > > > So you actually mean that for every change (big in size like 5-10+ files) whole code should be replaced with new release, while keeping an option of "roll-back" ? Bye, Viki.
Re: fixing bug in multiple releases
On Wed, Apr 21, 2010 at 4:27 AM, Vikrama Sanjeeva wrote: > Hi, > > Thanks Andy and David for your answers. > > As I said, it was just a supposition in a case where it becomes necessary to > fix all previous releases (for whatever reason). And in this case, I too > think not to touch the tag itself rather as per David's advise, branch the > tag 1.6, fix it and then release it as 1.6.1 tag. > > However, in my case, its a typical web application providing online > payment services to web users. Where, the chances of deploying previous > releases are very less. Because the advancement goes on with the new > features adding in site and making it more productive. This is a web-based service? In that case, there's probably little reason to fix the previous releases at all. Why fix release REL-1.4 if it isn't even deployed any more? I can see a situation where you have REL-1.6 deploy and are about to deploy REL-1.7. You deploy REL-1.7 and then are forced to rollback to REL-1.6. In that case, you probably want to fix the bug and roll our REL-1.6.1 while you're trying to fix the problem with REL-1.7. > Also, in case of web-applications what is the best practice to deploy REL-1.7 > on > production ? Do we replace whole REL-1.6 code with REL-1.7 or just update the > production with modified binaries of REL1.7 ? Do you have an automated deployment abilities? My preference is to have an automated way of deploying apps. You want to make sure that the binaries, database changes, and any preference file changes are all deployed and properly configured. Just replacing the binaries might not do it. -- David Weintraub qazw...@gmail.com
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
Bettual Richter wrote: >I'm trying to write a skript to set versioned properties after been >triggered by a >hook but I seem to get stuck finding a solution and hope someone here >is able to help me or point out if it's not possible. > >I'd like to set a property for every file in a certain >directory(recursivly) using >an url. Something like > >svn propedit -R PROPNAME PROPVAL URL >>I think you meant propset >> >>but anyhow svn prop* for versioned properties only work in on a >>working copy. Sry, but that's not right. svn propedit NAME VAL URL works without a working copy. I meant propedit and have tested it extensively because it allows you to set new properties(also versioned ones) see, http://subversion.tigris.org/issues/show_bug.cgi?id=2238 comment from Noritada Kobayashi Thu Feb 1 03:55:02 -0700 2007 It's the only hint I found to figure this out Anyway thx for your idea but it doesn't really work the way I need it. I tested it using the svnmucc --extra-arg FILE with following results : 1. FILE containing one operation per line e.g. 'propset NAME VAL URL' gives 'propset NAME VAL URL' is not an action 2. FILE containing each arg in a seperate line e.g. 'propset \n NAME \n VAL \n URL' gives a correct reply and sets the right property 3. FILE containing serveral versions of 2. e.g. 'propset \n NAME \n VAL \n URL \npropset \n NAME \n VAL \n URL' gives the same error as 1. Assuming propedit works on URLs(it does) I'm trying to do something like svn propedit NAME1 VAL1 URL1 svn propedit NAME2 VAL2 URL2 svn propedit NAME3 VAL3 URL3 at once. Most suitable with only one revision change. Any further ideas would make me happy :) thanks Bettual
RE: killer feature -- HEAD+1
> Hi David, > > David Brodbeck wrote on Tue, 20 Apr 2010 at 14:31 -0700: > > I'm more interested in the feature suggested by the +1 in the subject > > line -- the ability to get *future* revisions that haven't been > > committed yet. Just think, you could start a new project, then check > > out HEAD+8972 and get finished, debugged code! ;) > > > > This feature is available in Subversion 2.0. Please checkout > > https://svn.apache.org/repos/asf/subversion/tags/2.0.0/@HEAD+14310700 > > and give it a spin. > > > > > Thanks, > > Daniel Thank link seems to be broken. This one works much better: http://tinyurl.com/y77qy9c BOb
RE: killer feature -- HEAD+1
> 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: Bob Archer [mailto:bob.arc...@amsi.com] > Sent: 21 April 2010 15:35 > To: Daniel Shahaf; David Brodbeck > Cc: users@subversion.apache.org > Subject: RE: killer feature -- HEAD+1 > > > Hi David, > > > > David Brodbeck wrote on Tue, 20 Apr 2010 at 14:31 -0700: > > > I'm more interested in the feature suggested by the +1 in the > > > subject line -- the ability to get *future* revisions > that haven't > > > been committed yet. Just think, you could start a new > project, then > > > check out HEAD+8972 and get finished, debugged code! ;) > > > > > > > This feature is available in Subversion 2.0. Please checkout > > > > > > > https://svn.apache.org/repos/asf/subversion/tags/2.0.0/@HEAD+14310700 > > > > and give it a spin. > > > > > > > > > Thanks, > > > > Daniel > > Thank link seems to be broken. This one works much better: > > http://tinyurl.com/y77qy9c > You guys. LOL
Re: killer feature -- HEAD+1
On Wed, Apr 21, 2010 at 10:35:13AM -0400, Bob Archer wrote: > > Hi David, > > > > David Brodbeck wrote on Tue, 20 Apr 2010 at 14:31 -0700: > > > I'm more interested in the feature suggested by the +1 in the subject > > > line -- the ability to get *future* revisions that haven't been > > > committed yet. Just think, you could start a new project, then check > > > out HEAD+8972 and get finished, debugged code! ;) > > > > > > > This feature is available in Subversion 2.0. Please checkout > > > > https://svn.apache.org/repos/asf/subversion/tags/2.0.0/@HEAD+14310700 > > > > and give it a spin. > > > > > > > > > Thanks, > > > > Daniel > > Thank link seems to be broken. This one works much better: > > http://tinyurl.com/y77qy9c Which nicely demonstates improved tag handling in 2.0. Tags are instantly aliased via standard URL-shortening services, allowing Subversion-powered developers to propagate tag names to their co-workers more quickly (e.g. via various IM services). As promised, Subversion 2.0 integrates nicely with Web 2.0. Stefan
RE: killer feature -- HEAD+1
> On Wed, Apr 21, 2010 at 10:35:13AM -0400, Bob Archer wrote: > > > Hi David, > > > > > > David Brodbeck wrote on Tue, 20 Apr 2010 at 14:31 -0700: > > > > I'm more interested in the feature suggested by the +1 in the > subject > > > > line -- the ability to get *future* revisions that haven't been > > > > committed yet. Just think, you could start a new project, then > check > > > > out HEAD+8972 and get finished, debugged code! ;) > > > > > > > > > > This feature is available in Subversion 2.0. Please checkout > > > > > > > https://svn.apache.org/repos/asf/subversion/tags/2.0.0/@HEAD+14310700 > > > > > > and give it a spin. > > > > > > > > > > > > > Thanks, > > > > > > Daniel > > > > Thank link seems to be broken. This one works much better: > > > > http://tinyurl.com/y77qy9c > > Which nicely demonstates improved tag handling in 2.0. > Tags are instantly aliased via standard URL-shortening services, > allowing Subversion-powered developers to propagate tag names to > their co-workers more quickly (e.g. via various IM services). > As promised, Subversion 2.0 integrates nicely with Web 2.0. > > Stefan For some reason I feel this thread is about 20 days late... since all this was reveled at that time. BOb
Re: does "svn diff" has a bug for external items ?
On Wed, Apr 21, 2010 at 09:56:13AM +0200, Toralf Förster wrote: > Hello, > > I'm wondering whether this bug https://bugs.gentoo.org/show_bug.cgi?id=309183 > is Gentoo specific or worth to be filed in svn bug tracking system too. I cannot reproduce your problem (using Subversion trunk) using the svn commands you gave in the issue. I get a nice diff instead. Please try to pin down the problem a bit further before filing a bug in our tracker. The output that says: Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) Index: tcpip.cc looks as if the external diff is printing garbage. Which external diff tool are you using? Can you try to find out where this QDBUS stuff is coming from? Can you also provide information about your Subversion build? What configuration and which compile-time dependencies are you using? Stefan
How to speed up subversion
I have a working copy/respository with many files that are several hundred MB each. Whenever I try to check the status of my working copy or do a commit, it can take a long time (~1 min) before I get a response. I don't have any externals and the number of total files in my repository is ~100. Has anyone else experienced this or knows how to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. Thanks, Jeremy
Re: fixing bug in multiple releases
On Wed, Apr 21, 2010 at 5:18 PM, David Weintraub wrote: > On Wed, Apr 21, 2010 at 4:27 AM, Vikrama Sanjeeva > wrote: > > Hi, > > > > Thanks Andy and David for your answers. > > > > As I said, it was just a supposition in a case where it becomes necessary > to > > fix all previous releases (for whatever reason). And in this case, I too > > think not to touch the tag itself rather as per David's advise, branch > the > > tag 1.6, fix it and then release it as 1.6.1 tag. > > > > However, in my case, its a typical web application providing online > > payment services to web users. Where, the chances of deploying previous > > releases are very less. Because the advancement goes on with the new > > features adding in site and making it more productive. > > This is a web-based service? In that case, there's probably little > reason to fix the previous releases at all. Why fix release REL-1.4 if > it isn't even deployed any more? > > I can see a situation where you have REL-1.6 deploy and are about to > deploy REL-1.7. You deploy REL-1.7 and then are forced to rollback to > REL-1.6. > > In that case, you probably want to fix the bug and roll our REL-1.6.1 > while you're trying to fix the problem with REL-1.7. > Agreed. > > > Also, in case of web-applications what is the best practice to deploy > REL-1.7 on > > production ? Do we replace whole REL-1.6 code with REL-1.7 or just update > the > > production with modified binaries of REL1.7 ? > > Do you have an automated deployment abilities? My preference is to > have an automated way of deploying apps. You want to make sure that > the binaries, database changes, and any preference file changes are > all deployed and properly configured. Just replacing the binaries > might not do it. > We don't have automated deployment process. Normally, its compiled code which has to go in certain hierarchy on production whenever we have change. We normally do this by transferring binaries via FTP which is fast and working effeciently since last year without any error. However, in case of database, we have scripts to database department which cross-checks the scripts and run accordingly. In case of roll-back we normally do not touch database. There might be a need to do this, but we never had a situation. However, my one question is still left un-answered. I will appreciate if you can guide in this regards. *David says: > * *That said, let's say you're working on REL-1.7, but it isn't ready, and a > bad bug was found in REL-1.6. You should copy the tag REL-1.6 to a branch, > fix the bug on the branch, and then create a new REL-1.6.1 tag. That way, > you can see that you had a REL-1.6 and what changes you had to make to get > to REL-1.6.1. If you change the tag, you lose this information. Plus, you > end up with two REL-1.6s: One with the patch and one without. How are you > going to know the difference between the two REL-1.6.* > In this case, how I will update the bug fix in REL-1.7 which I fixed in 1.6.1 tag ? Is it the developer's responsibility to redo the bug fixing steps on REL-1.7 which he did in REL1.6 ? Or is there any automated process provided by SVN ? Because latest development is going on REL-1.7 which do posses the bug of REL1.6. Bye, Viki.
Re: How to speed up subversion
On 4/21/2010 10:48 AM, Jeremy Conlin wrote: I have a working copy/respository with many files that are several hundred MB each. Whenever I try to check the status of my working copy or do a commit, it can take a long time (~1 min) before I get a response. I don't have any externals and the number of total files in my repository is ~100. Has anyone else experienced this or knows how to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. What client-server protocol are you using? This could be a problem with DNS or the authentication method besides whatever svn has to do. -- Les Mikesell lesmikes...@gmail.com
Re: How to speed up subversion
On Wed, Apr 21, 2010 at 9:58 AM, Les Mikesell wrote: > On 4/21/2010 10:48 AM, Jeremy Conlin wrote: >> >> I have a working copy/respository with many files that are several >> hundred MB each. Whenever I try to check the status of my working >> copy or do a commit, it can take a long time (~1 min) before I get a >> response. I don't have any externals and the number of total files in >> my repository is ~100. Has anyone else experienced this or knows how >> to speed things up? I'm running svn 1.6.5 on Mac OSX 10.6.2. > > What client-server protocol are you using? This could be a problem with DNS > or the authentication method besides whatever svn has to do. I am using svn+ssh. I have several other repositories located on the same server. These repositories are smaller in the number of MB and they also have no speed issues as I have with the "big" one. Jeremy
Re: fixing bug in multiple releases
On 4/21/2010 8:48 AM, Vikrama Sanjeeva wrote: Also, in case of web-applications what is the best practice to deploy REL-1.7 on production ? Do we replace whole REL-1.6 code with REL-1.7 or just update the production with modified binaries of REL1.7 ? Normally you would want to work in a way that gives you a known 'roll-back' state in case the next change introduces problems. If you don't keep a whole release together you'll have to track the individual changes to know how to reproduce the last working state. So you actually mean that for every change (big in size like 5-10+ files) whole code should be replaced with new release, while keeping an option of "roll-back" ? There are different tradeoffs depending on how the application works and where you need to deploy, but a good arrangement is to have a 'staging' server where you can update or switch to a release tag and execute/test directly from the workspace, then use a scripted 'rsync -C ...' type of command to propagate to the production server(s). Rsync is smart enough to (a) only copy the changes and (b) receive under a different name, renaming only when the transfer is complete and successful. If you never make changes in the staging workspace you guarantee that what you test and push to production is a reproducible copy from the subversion repository that you can recall if you need to revert to that version later. -- Les Mikesell lesmikes...@gmail.com
Re: Recursive setting of versioned properties using URL using propedit or svnmucc
On Apr 21, 2010, at 09:27, Bettual Richter wrote: > On Apr 21, 2010, at 07:19, Lorenz wrote: >> Bettual Richter wrote: >>> I'd like to set a property for every file in a certain >>> directory(recursivly) using an url. Something like >>> >>> svn propedit -R PROPNAME PROPVAL URL >>> >> >> I think you meant propset >> >> but anyhow svn prop* for versioned properties only work in on a >> working copy. >> > > Sry, but that's not right. > > svn propedit NAME VAL URL > > works without a working copy. I meant propedit and have > tested it extensively because it allows you to set > new properties(also versioned ones) see, > http://subversion.tigris.org/issues/show_bug.cgi?id=2238 > comment from Noritada Kobayashi Thu Feb 1 03:55:02 -0700 2007 > It's the only hint I found to figure this out True, svn propedit can be used on URLs now. But "svn propedit NAME VAL URL" is not right. propedit does not take a VAL argument on the command line; rather, it opens an editor and you type the value there. Also, svn propedit is for editing a single property of a single file or directory. Since you want to edit properties of multiple files, svn propedit is not going to work. > Anyway thx for your idea but it doesn't really work the way I need it. > > I tested it using the svnmucc --extra-arg FILE with following results : > > 1. FILE containing one operation per line > e.g. 'propset NAME VAL URL' > gives 'propset NAME VAL URL' is not an action > 2. FILE containing each arg in a seperate line > e.g. 'propset \n NAME \n VAL \n URL' > gives a correct reply and sets the right property Yes, according to "svnmucc --help", its --extra-args option requires one argument per line in the file. > 3. FILE containing serveral versions of 2. > e.g. 'propset \n NAME \n VAL \n URL >\npropset \n NAME \n VAL \n URL' > gives the same error as 1. Are you sure? I was able to get svnmucc to do two operations by just listing them one after another in the extra args file: cp 1 file:///tmp/repo/foo file:///tmp/repo/foo2 cp 1 file:///tmp/repo/foo file:///tmp/repo/foo3 Though I am using the cp command here, and not propset; the propset command is not working for me for some reason; I'm getting the same error you reported earlier: svnmucc: File already exists: filesystem '/tmp/repo/db', transaction '2-3', path '/foo' > Assuming propedit works on URLs(it does) I'm trying to do something like > > svn propedit NAME1 VAL1 URL1 > svn propedit NAME2 VAL2 URL2 > svn propedit NAME3 VAL3 URL3 > at once. > Most suitable with only one revision change. propedit does work on URLs, but only on one URL at a time. Doing multiple actions in a single revision change without having a working copy is only possible using the svnmucc tool; that's the purpose of the svnmucc tool in fact. The other option already mentioned is to do your changes in a working copy. Those are the two options I'm aware of for accomplishing what you want. Well, the third option would be to write a program to do this using the Subversion language bindings. But that's a lot of work, and probably unnecessary since the other two methods suggested above should work and are easier.
Re: fixing bug in multiple releases
On Wed, Apr 21, 2010 at 8:13 PM, Les Mikesell wrote: > On 4/21/2010 8:48 AM, Vikrama Sanjeeva wrote: > >> >> > >>Also, in case of web-applications what is the best practice to >>deploy REL-1.7 on production ? Do we replace whole REL-1.6 code >>with REL-1.7 or just update the production with modified >>binaries of REL1.7 ? >> >> >>Normally you would want to work in a way that gives you a known >>'roll-back' state in case the next change introduces problems. If >>you don't keep a whole release together you'll have to track the >>individual changes to know how to reproduce the last working state. >> >> >> So you actually mean that for every change (big in size like 5-10+ >> files) whole code should be replaced with new release, while keeping an >> option of "roll-back" ? >> > > There are different tradeoffs depending on how the application works and > where you need to deploy, but a good arrangement is to have a 'staging' > server where you can update or switch to a release tag and execute/test > directly from the workspace, then use a scripted 'rsync -C ...' type of > command to propagate to the production server(s). Rsync is smart enough to > (a) only copy the changes and (b) receive under a different name, renaming > only when the transfer is complete and successful. If you never make > changes in the staging workspace you guarantee that what you test and push > to production is a reproducible copy from the subversion repository that you > can recall if you need to revert to that version later. > > -- > Les Mikesell > lesmikes...@gmail.com > Agreed. We do use staging for testing and UAT with client and if all works good then only planned deployment is done on production. However, I like your idea of "rsync -C.." command for deploying "accurate" changes from staging to production. But I think in this case, deployment engineer should be confident that only change related to a specific feature is present on staging and ready to ship on production. Because, if there are multiple features residing in staging but only certain features qualifies for production then running "rsync -C..." will be expensive. Bye, Viki,
