(In the discussion that follows, I use "client" in the sense of client application which talks to a server application; not the perforce sense of client == workspace == working copy.)
Okay, here's what I meant. To be totally safe, check in all the changes you care about using the old client, then install the new client. Your working copy will putatively continue to work with the new client. It's the "putatively" that makes me say "to be totally safe". However, if you find a problem with svn 1.4, and you want to go back to svn 1.3.1, the changes that 1.4 made to your working copy have made the working copy unusable with 1.3.1. This is all just general paranoia of lost work. The normal path is just to install the new svn 1.4 client and keep using your current working copy. 1) install svn 1.4 2) continue using your existing working copy The safer method is 1) using 1.3.1, check in any outstanding changes from any workspace that you care about. 2) move the 1.3.1 svn binary somewhere safe 3) install svn 1.4 4) continue using your existing working copy The ultra paranoid safe but slow way of doing it is the safe method, but replace step 4 with 4') check out a new working copy Me, I'm going to do the normal path. -ben On Sep 21, 2006, at 7:42 AM, P T Withington wrote: > I don't understand your comment. You seem to be telling us to get > the new svn client (1.4) because it is much better than the old > client, but then telling us we shouldn't because the new client > will make your playpen not work with the old client. But, if I > have the new client, why would I need the old client to work? > > Oh, svn sage, please make clear your wisdom! > > On 2006-09-20, at 17:04 EDT, Benjamin Shine wrote: > >> No, but it will make your working copy no longer work with pre-1.4 >> clients. So I wouldn't switch if you have outstanding changes you >> care about. >> >> On Sep 20, 2006, at 1:51 PM, Henry Minsky wrote: >> >>> I assume this requires checking out new working copies, right? >>> >>> >>> On 9/20/06, Benjamin Shine <[EMAIL PROTECTED] > wrote: >>> As of September 10, svn 1.4 has been released. mac binaries >>> available >>> at http://www.codingmonkeys.de/mbo/ and the new client should work >>> with our server, which is running 1.2.3. The upgrade seems like >>> it is >>> worth doing for the working copy performance improvements and these >>> two new subcommands: >>> >>> svn diff/merge -c/--change >>> You can now simply write -c N to view or merge a single >>> revision, instead of the cumbersome -r N-1:N. >>> svn diff --summarize >>> Prints only the list of changed files, in the output format of >>> 'svn status'. This lets you retrieve summaries of changes directly >>> from a repository, whereas 'svn status' operates only on the local >>> changes of your working copy. >>> >>> and >>> * numerous working copy improvements (WARNING! upgrades to new >>> format!): >>> - improved performance when detecting modified files >>> (r18628 -56) >>> - new property storage is faster and uses less disk space >>> (r17583) >>> - internal wcprops take up less space (r19433 -37) >>> - large file commit speedups (r17861 -73 18867 -918 -29 -44 >>> -45 -48 -49) >>> - reduce memory usage for large working copies (r19183 -538) >>> - increased working copy stability with merge, copy and move: >>> (fixes issues #845, #1516, #1553, #2135, #2144, #2148) >>> >>> The way in which the Subversion client manages your working copy has >>> undergone radical changes. The .svn/entries file is no longer XML, >>> and the client has become smarter about the way it manages and >>> stores >>> property metadata. >>> >>> As a result, there are substantial performance improvements. The new >>> working copy format allows the client to more quickly search a >>> working copy, detect file modifications, manage property metadata, >>> and deal with large files. The overall disk footprint is smaller as >>> well, with fewer inodes being used. Additionally, a number of long >>> standing bugs related to merging and copying have been fixed. >>> >>> >>> >>> _______________________________________________ >>> Laszlo-dev mailing list >>> [email protected] >>> http://www.openlaszlo.org/mailman/listinfo/laszlo-dev >>> >>> >>> >>> -- >>> Henry Minsky >>> Software Architect >>> [EMAIL PROTECTED] >>> >> >> _______________________________________________ >> IT mailing list >> [EMAIL PROTECTED] >> https://hedwig.laszlosystems.com/mailman/listinfo/it > _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
