Also, svnX is incompatible with subversion 1.4 working copies, as of svnX version 0.9.8. Once you use command-line svn 1.4 on a working copy, svnX will no longer be able to make much sense of that working copy.
-ben On Sep 22, 2006, at 1:36 PM, Benjamin Shine wrote: > > (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 _______________________________________________ Laszlo-dev mailing list [email protected] http://www.openlaszlo.org/mailman/listinfo/laszlo-dev
