I've spent several hours playing with the Subversion Boost repository that Troy Straszheim was kind enough to set up. Here is my initial experience: * The downloads and installation of WxWidgets, Subversion, and RapidSVN went smoothly; everything worked right away the first try. * The initial Boost checkout using RapidSVN worked right away the first try. However, there doesn't seem to be any RapidSVN documentation, so if you aren't already familiar with WinCVS or similar, you might have more trouble. ***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users. * Boost Subversion updates are much faster than CVS; with CVS it took over 12 minutes this morning, versus a bit more than one minute with Subversion/RapidSVN. * Starting RapidSVN on the Boost SVN working copy is very slow; over 60 seconds if the machine has just been turned on. The disk is being worked hard. 10 seconds if the cache is warm. For comparison, WinCVS starts in a second or so, even on a cold disk cache. * The Subversion revision numbering scheme is so different from CVS that it will take quite a bit of reorientation (at least for me) to learn how to use it. It is very counter-intuitive for me that the previous revision of a file isn't 12345 if the current revision is 12346. I found myself constantly having to run "log" to figure out what the previous revision was. I often look at past revisions, so this is important to me. I suppose there is some way to do this as easily as with CVS, but I haven't figured that out yet. * RapidSVN doesn't save location on exit, so every time you start it up you have to navigate to wherever you want to be. It also crashed on me several times. My sense is it is a nice piece of software, but also very immature as yet. * The branching and tagging approaches seem different; we would have to work out new best practices before switching to SVN. --Beman
Beman Dawes wrote:
[...] ***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users.
My guess is that the client doesn't properly do compression. From http://subversion.tigris.org/: * Apache network server option, with WebDAV/DeltaV protocol. Subversion can use the HTTP-based WebDAV/DeltaV protocol for network communications, and the Apache web server to provide repository-side network service. This gives Subversion an advantage over CVS in interoperability, and provides various key features for free: authentication, path-based authorization, wire compression, and basic repository browsing. So I guess that's a point in favor of an HTTP server over svnserve. Apparently, there are some issues with some of the SVN clients and compression, so it doesn't seem unreasonable that RapidSVN is one of them, considering that it's a pre-release product. On the other hand, TortoiseSVN seems decently mature, and apparently leverages the experience of TortoiseCVS.
[...] * Starting RapidSVN on the Boost SVN working copy is very slow; over 60 seconds if the machine has just been turned on. The disk is being worked hard. 10 seconds if the cache is warm. For comparison, WinCVS starts in a second or so, even on a cold disk cache.
Perhaps another point against RapidSVN...for now. TortoiseSVN has zero startup time, because it's really just a set of shell extensions for Windows Explorer. Pretty hard to beat that (except with TortoiseCVS, of course ;). If it isn't obvious by now, I'm suggesting that you give TortoiseSVN a try. It might seem a little cutesy at first, but I think you will be delightfully surprised at how easy it is to use.
* The Subversion revision numbering scheme is so different from CVS that it will take quite a bit of reorientation (at least for me) to learn how to use it. It is very counter-intuitive for me that the previous revision of a file isn't 12345 if the current revision is 12346. I found myself constantly having to run "log" to figure out what the previous revision was. I often look at past revisions, so this is important to me. I suppose there is some way to do this as easily as with CVS, but I haven't figured that out yet.
This is one of those things that is just going to be different for SVN. As far as SVN is concerned, there are no such things as "tags" and "branches" and "trunks" and "projects" and "changesets" or anything like that. To SVN, each transaction on a repository, no matter *what* part of the repository, introduces a new repository tree, and that is exclusively what SVN traffics in. That is why changes are numbered with a global revision, rather than a per-file revision. Yes, that is quite contrary to the way CVS does it, and no, I don't think there is an easy way to get CVS-like behavior. On the other hand, if you want to see an old revision in TortoiseSVN, you just do a Show Log and double-click on the revision of your choice. Not sure if it makes a difference what the revision numbers are then, as long as they are in order.
* RapidSVN doesn't save location on exit, so every time you start it up you have to navigate to wherever you want to be. It also crashed on me several times. My sense is it is a nice piece of software, but also very immature as yet.
That's probably true. Which is why you should take a look at TortoiseSVN. ;)
* The branching and tagging approaches seem different; we would have to work out new best practices before switching to SVN.
The SVN book suggests some best practices, which Troy has aparently followed. To accomodate the CVS style of thinking, he's created top-level trunk/tags/branches directories which hold the various tree copies. But as someone else mentioned, there is no compelling reason to do things this way, and it would be just as easy to call the tags folder "releases". Dave
At 01:31 PM 2/5/2005, David B. Held wrote:
* RapidSVN doesn't save location on exit, so every time you start it up
you have to navigate to wherever you want to be. It also crashed on me several times. My sense is it is a nice piece of software, but also very immature as yet.
That's probably true. Which is why you should take a look at TortoiseSVN. ;)
OK... Yep, TortoiseSVN seems much more mature than RapidSVN. It reduced the checkout byte count to something fairly reasonable, etc. The reason I prefer a separate client to the explore plug-in is to be able to see the branch/tag. That prevents mistakes due to me being confused about which branch/tag/revision is currently the working copy for a file. Perhaps that isn't a problem with Subversion, or there is a way to get TortoiseSVN to display the current branch/tag, or at least some indication that the current copy is not the HEAD. Thanks, --Beman
Beman Dawes wrote:
At 01:31 PM 2/5/2005, David B. Held wrote:
* RapidSVN doesn't save location on exit, so every time you start it up
you have to navigate to wherever you want to be. It also crashed on me >> several times. My sense is it is a nice piece of software, but also very immature as yet.
That's probably true. Which is why you should take a look at TortoiseSVN. ;)
OK...
Yep, TortoiseSVN seems much more mature than RapidSVN. It reduced the checkout byte count to something fairly reasonable, etc.
The reason I prefer a separate client to the explore plug-in is to be able to see the branch/tag. That prevents mistakes due to me being confused about which branch/tag/revision is currently the working copy for a file. Perhaps that isn't a problem with Subversion, or there is a way to get TortoiseSVN to display the current branch/tag, or at least some indication that the current copy is not the HEAD.
You can find out which repository directory a particular SVN local directory is referencing by right-clicking, going into the TortoiseSVN submenu and choosing Repo Browser. A TortoiseSVN setting ( TortoiseSVN sub-menu | Settings | Look and Feel | Context Menu ) lets you put the TortoiseSVN submenu Repo Browser directly in your right-clicked main menu. A good suggestion to the TortoiseSVN people on the NG might be to put the full repository path referenced by an SVN local directory directly on the right-click submenu, at least as an option, to make it even easier to see what repository path an SVN local directory references.
At 06:27 PM 2/5/2005, Edward Diener wrote:
You can find out which repository directory a particular SVN local directory is referencing by right-clicking, going into the TortoiseSVN submenu and choosing Repo Browser. A TortoiseSVN setting ( TortoiseSVN sub-menu | Settings | Look and Feel | Context Menu ) lets you put the TortoiseSVN submenu Repo Browser directly in your right-clicked main menu. A good suggestion to the TortoiseSVN people on the NG might be to put the full repository path referenced by an SVN local directory directly on the right-click submenu, at least as an option, to make it even easier to see what repository path an SVN local directory references.
There is a better way: View | Choose Details, then scroll the list down. If the directory has any SVN stuff, there are check boxes for SVN status, revision, URL, etc. Check the choices you prefer. --Beman
Beman Dawes wrote:
At 06:27 PM 2/5/2005, Edward Diener wrote:
You can find out which repository directory a particular SVN local directory is referencing by right-clicking, going into the TortoiseSVN submenu and >choosing Repo Browser. A TortoiseSVN setting ( TortoiseSVN sub-menu | >Settings | Look and Feel | Context Menu ) lets you put the TortoiseSVN >submenu Repo Browser directly in your right-clicked main menu. A good >suggestion to the TortoiseSVN people on the NG might be to put the full >repository path referenced by an SVN local directory directly on the >right-click submenu, at least as an option, to make it even easier to see >what repository path an SVN local directory references.
There is a better way: View | Choose Details, then scroll the list down. If the directory has any SVN stuff, there are check boxes for SVN status, revision, URL, etc. Check the choices you prefer.
Yes, I see that. Powerdesk does not show it but Explorer does. Your find reinforces my point in how user friendly TortoiseDVN is <g>..
Beman Dawes wrote:
***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users.
800 MB is a lot more than Boost's size. Could it be you downloaded all revisions of Boost? If the tool that was used to create the SVN repository uses a layout similar to what is proposed in the SVN book and if the tools created tags analogue to what was present in the CVS then you should checkout the /trunk subdirectory for getting the head revision only. If you omit the /trunk then you get all versions ever tagged. Regards, m
Martin Wille wrote:
[...] 800 MB is a lot more than Boost's size. Could it be you downloaded all revisions of Boost?
If the tool that was used to create the SVN repository uses a layout similar to what is proposed in the SVN book and if the tools created tags analogue to what was present in the CVS then you should checkout the /trunk subdirectory for getting the head revision only. If you omit the /trunk then you get all versions ever tagged.
Heh, that's a good point. That's what I did just now, and it is indeed a very large download. It can be handy to have local copies of multiple branches if you want to do diffs and stuff, but most people probably don't need every branch and tag ever created. I'm sure just checking out the trunk is very similar in speed to CVS. Dave
At 02:17 PM 2/5/2005, Martin Wille wrote:
Beman Dawes wrote:
***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes
had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users.
800 MB is a lot more than Boost's size. Could it be you downloaded all revisions of Boost?
It is some problem with the RapidSVN client. The same download with TortoiseSVN had a received byte count of 19 megs. More than CVS, but not totally objectionable. --Beman
Beman Dawes wrote:
I've spent several hours playing with the Subversion Boost repository that Troy Straszheim was kind enough to set up. Here is my initial experience:
* The downloads and installation of WxWidgets, Subversion, and RapidSVN went smoothly; everything worked right away the first try.
* The initial Boost checkout using RapidSVN worked right away the first try. However, there doesn't seem to be any RapidSVN documentation, so if you aren't already familiar with WinCVS or similar, you might have more trouble.
TortoiseSVN under Windows is much easier to use than RapidSVN. It integrates with most any Explorer-like interface ( I am using it with Powerdesk, which is an Explorer-like file manager with some extra bells-and-whistles).
***** Serious Problem ***** The initial checkout seemed to be working my DSL connection pretty hard, so I started Task Manager and monitored "bytes received". By the time the checkout finished, over 800 megabytes had been received! I tried a completely fresh CVS checkout for comparison; the received byte count was 12.5 megabytes. CVS uses compression (although you have to remember to turn it on); I couldn't find any mention of a compression option in the SVN docs, and a search of RapidSVN menus didn't turn up any way to turn on compression. We would need to solve this problem since 800 megabyte checkouts aren't acceptable for dial-up users.
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
I didn't have deflation turned on in the http server. Sorry for the confusion. How does it look now? 68.255.31.159 - - [05/Feb/2005:12:32:41 -0800] "PROPFIND /boost/!svn/bc/19699/trunk/boost/io/ios_state.hpp HTTP/1.1" 207 358 mod_deflate: 48 pct. 68.255.31.159 - - [05/Feb/2005:12:32:41 -0800] "PROPFIND /boost/trunk/boost/io/ios_state.hpp HTTP/1.1" 207 350 mod_deflate: 47 pct. 68.255.31.159 - - [05/Feb/2005:12:32:41 -0800] "PROPFIND /boost/!svn/vcc/default HTTP/1.1" 207 258 mod_deflate: 52 pct.
troy d. straszheim wrote:
Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
I didn't have deflation turned on in the http server. Sorry for the confusion. How does it look now?
No difference. My guess is any compression occurs on the server repository, not on the .svn directories created on the client side.
Edward Diener wrote:
troy d. straszheim wrote:
Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
I didn't have deflation turned on in the http server. Sorry for the confusion. How does it look now?
No difference. My guess is any compression occurs on the server repository, not on the .svn directories created on the client side.
There are two things going on here... The first is how much space a checkout takes up on local disk, and SVN is going to be probably twice as large as CVS, because it caches an entire copy of the checkout, which is why "svn diff" is very fast and works when you're offline. (*sweet*) Am I correct in thinking that 288MB and 96MB, above, correspond to on-disk size? The other was network bandwidth, which Beman brought up, which I guess came up because he got a copy of the trunk *and* all the branches... anyhow I found the business about deflation deep in the apache config files and made sure it was on. It did not appear to have been on before, but I guess it could have been... I'm not exactly Mr. Apache. Anyhow this deflation stuff appears to be equivalent to what CVS does, I'd say it's not an issue. -t
troy d. straszheim wrote:
Edward Diener wrote:
troy d. straszheim wrote:
Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
I didn't have deflation turned on in the http server. Sorry for the confusion. How does it look now?
No difference. My guess is any compression occurs on the server repository, not on the .svn directories created on the client side.
There are two things going on here... The first is how much space a checkout takes up on local disk, and SVN is going to be probably twice as large as CVS, because it caches an entire copy of the checkout, which is why "svn diff" is very fast and works when you're offline. (*sweet*) Am I correct in thinking that 288MB and 96MB, above, correspond to on-disk size?
Yes, that is correct. That does not bother me, perhaps because I have much disk space and a DSL connection. I do not know whether it will bother others. As far as download speed, I think SVN was actually faster than CVS but I did not bother to time it. If I had a dial-up modem instead, perhaps I would have done so.
On Sat, Feb 05, 2005 at 06:17:16PM -0500, Edward Diener wrote:
troy d. straszheim wrote:
Edward Diener wrote:
troy d. straszheim wrote:
Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each ?
I didn't have deflation turned on in the http server. Sorry for the confusion. How does it look now?
No difference. My guess is any compression occurs on the server repository, not on the .svn directories created on the client side.
There are two things going on here... The first is how much space a checkout takes up on local disk, and SVN is going to be probably twice as large as CVS, because it caches an entire copy of the checkout, which is why "svn diff" is very fast and works when you're offline. (*sweet*) Am I correct in thinking that 288MB and 96MB, above, correspond to on-disk size?
Yes, that is correct.
That does not bother me, perhaps because I have much disk space and a DSL connection. I do not know whether it will bother others. As far as download speed, I think SVN was actually faster than CVS but I did not bother to time it. If I had a dial-up modem instead, perhaps I would have done so.
Hi, I'm using svn for almost a year now as a production system. From my experience, svn updates are much faster then cvs. Also traffic is smaller once you get the repository, since the commit sends patches both ways, unlike the cvs. I can also confirm, that it works very well over a dial-up connection. One of my collegues is using it like that. Although we do the initial checkout on some faster connection (and transport the repository on CD to his machine). Once, the repository is there, is works reasonably well through the modem. Regards, Pavol
On Sat, 5 Feb 2005 18:17:16 -0500, Edward Diener wrote
There are two things going on here... The first is how much space a checkout takes up on local disk, and SVN is going to be probably twice as large as CVS, because it caches an entire copy of the checkout, which is why "svn diff" is very fast and works when you're offline. (*sweet*) Am I correct in thinking that 288MB and 96MB, above, correspond to on-disk size?
Yes, that is correct.
That does not bother me, perhaps because I have much disk space and a DSL connection. I do not know whether it will bother others. As far as download speed, I think SVN was actually faster than CVS but I did not bother to time it. If I had a dial-up modem instead, perhaps I would have done so.
Well my results are 'interesting'. Like Edward my on disk size for SVN is 288MB and CVS is 96MB -- this is on WinXP. I put a network snooper (ethereal) on while doing a full checkout and the results are a bit odd: Packets Bytes Time (minutes) TurtleSVN 21,846 19,608,899 ~6 WinCVS 77,184 69,223,709 ~4.5 I don't have an explanation for the results other than the possibility the in fact there is more compression with TurtleSVN. Frankly I'm dubious about the measurements except the part where SVN was 1.5 minutes slower... Otherwise, TurtleSVN seems easy to use and does a nice job. I was able to modify a file, do a check-in, see the log changes. For basic 'head-based' development it seems like the learning time was very small. I really like the SVN URL approach for the repository path. This is so much easier to understand the the CVS root :pserver:blah_blah_blah stuff (I had to spend 5 minutes remembering how to do that again with WinCVS). One problem I encounted was an error when I tried to run a 'revision graph' on a file. The file is: libs/date_time/xmldoc/gregorian_autodoc.boostbook The error is: REPORT request failed on /boost/!svn/bc/19699 The REPORT request returned invalid XML in the response: XML parse error at the line 203135:not well-formed (invalid token)(/boost/!svn/bc/19699) Not sure if this is a TortoiseSVN problem or something about the repository setup. Jeff ps: Double thx to Troy for setting this up -- it has been very helpful!
At 07:20 PM 2/5/2005, Jeff Garland wrote:
Well my results are 'interesting'. Like Edward my on disk size for SVN is 288MB and CVS is 96MB -- this is on WinXP. I put a network snooper (ethereal) on while doing a full checkout and the results are a bit odd:
Packets Bytes Time (minutes) TurtleSVN 21,846 19,608,899 ~6 WinCVS 77,184 69,223,709 ~4.5
Those results (except timings) are almost exactly the same as mine, except for the WinCVS byte count over the wire. In WinCVS: Admin | Preferences... | Globals, what is your "Compression level" set to? Mine is 9. I'm guessing yours is set lower. Time comparisons don't mean a whole lot, since two very different servers are involved. I'm quite impressed with TortoiseSVN. Maybe I'll even read the manual:-) --Beman
On Sat, 05 Feb 2005 19:51:34 -0500, Beman Dawes wrote
Those results (except timings) are almost exactly the same as mine, except for the WinCVS byte count over the wire.
In WinCVS: Admin | Preferences... | Globals, what is your "Compression level" set to? Mine is 9. I'm guessing yours is set lower.
The box is unchecked which I think means there isn't any.
Time comparisons don't mean a whole lot, since two very different servers are involved.
Agree.
I'm quite impressed with TortoiseSVN. Maybe I'll even read the manual:-)
Actually, I think it is testiment to the design to NOT have to read the manual... Jeff
Jeff Garland wrote:
On Sat, 05 Feb 2005 19:51:34 -0500, Beman Dawes wrote [...]
I'm quite impressed with TortoiseSVN. Maybe I'll even read the manual:-)
Actually, I think it is testiment to the design to NOT have to read the manual...
Manual? You mean TortoiseSVN *has* a manual?? ;> And if it does, do we really need to go that far? ;> Dave
At 04:25 AM 2/6/2005, David B. Held wrote:
Jeff Garland wrote:
On Sat, 05 Feb 2005 19:51:34 -0500, Beman Dawes wrote [...]
I'm quite impressed with TortoiseSVN. Maybe I'll even read the manual:-)
Actually, I think it is testiment to the design to NOT have to read the manual...
Manual? You mean TortoiseSVN *has* a manual?? ;> And if it does, do we really need to go that far? ;>
Well, I also think it is a testament to the design to be able to do many common operations without reference to the manual (which is available by selecting the "Help" menu item. But TortoiseSVN's manual is really good. One of the best I've seen in a long time. It includes a lot of tutorial material, and has a large "Daily Use Guide" section of task oriented documentation for common user tasks. Coupled with the strong GUI design, it allowed me to come up to speed much more quickly than usual. I set up a local repository this morning. My initial attempt clearly got the directory hierarchy wrong. When that has happened to me with CVS, I've always had to delete the repository and start over. With TortoiseSVN, I just did some repository moves of the offending directories, and was up and running in no time. Very slick. --Beman
Jeff Garland wrote:
One problem I encounted was an error when I tried to run a 'revision graph' on a file. The file is:
libs/date_time/xmldoc/gregorian_autodoc.boostbook
The error is:
REPORT request failed on /boost/!svn/bc/19699 The REPORT request returned invalid XML in the response: XML parse error at the line 203135:not well-formed (invalid token)(/boost/!svn/bc/19699)
Not sure if this is a TortoiseSVN problem or something about the repository setup.
svn doesn't really have support for revision graphs itself, so the authors of TSVN have tried to simulate them. The code has only just appeared in TSVN, and so isn't very mature yet (read beta). The devel list for tortoisesvn is very useful, the developers monitor it all day and there are nightly builds available at http://mapcar.org/tsvn-snapshots/latest as they tend to fix reproducible bugs that day but the official releases aren't quite as often. Cheers Russell
At 02:44 PM 2/5/2005, Edward Diener wrote:
My numbers are 288 MB for SVN and 96 MB for CVS. I have checked out only the latest Boost directory structure from both. That 3-1 margin is bothersome but is not the margin you reported. Is it possible that your numbers do not take into account the same files being checked out by each?
I was reporting how many bytes came over the wire. Your figures are for disk usage. My disk usage: SVN size 127 MB, size on disk 293 MB, files 52,259, directories 8,799. CVS size 61 MB, size on disk 96 MB, files 14,066, directories 1,493. While the disk difference is a bit unsettling, it probably isn't a showstopper for most people. I was particularly concerned with volume of data over the net, because if too large it would be a showstopper for those with dial-up connections. --Beman
Beman Dawes wrote:
[...] My disk usage:
SVN size 127 MB, size on disk 293 MB, files 52,259, directories 8,799. CVS size 61 MB, size on disk 96 MB, files 14,066, directories 1,493.
While the disk difference is a bit unsettling, it probably isn't a showstopper for most people. I was particularly concerned with volume of data over the net, because if too large it would be a showstopper for those with dial-up connections.
Like others have pointed out, SVN caches the latest update locally, which makes diffing your local changes very easy. That's why it's almost exactly twice the size of CVS. I think it's a reasonably small price to pay, not to mention a good tradeoff to reduce network bandwidth, since disk capacity is almost always cheaper than bandwidth. In fact, local caching is necessary to achieve the 2-way diff, which is really the major win. The fact that you get a fast local history is just a nice side effect that I think indicates an elegant design. Dave
participants (8)
-
Beman Dawes -
David B. Held -
Edward Diener -
Jeff Garland -
Martin Wille -
Pavol Droba -
Russell Hind -
troy d. straszheim