On Sun, Dec 03, 2006 at 04:20:10AM +0100, EdorFaus wrote: > On 11/30/06, Tin Newsom <[EMAIL PROTECTED]> wrote:
> > If you are keeping a copy of the current versions locally then diffing and > > sending only the diffs would be easy... but to my knowledge svn only keeps > > the diffs between versions at the repository. Someone who knowns please > As far as I know, this is essentially correct - the repository contains the > original file, and the diff for each version since then. This is, afterall, > enough to recreate any version. Actually, it's a little bit more tricky. They don't keep consecutive diffs but diffs to get to the next lower 2^N revision. With this method they can retrieve a specific revision with O(log N) instead of O(N). This costs more disk space than storing consecutive diffs. But since the repository is on the server, that should not harm in this application. After all, disks are cheap nowadays. Google for "delta combiner" or "skip deltas" if you are interested in details on this. But the delta's are only internal storage format. For transport, always diffs against the "base revision" (see below) are used. Using apache for repository serving, those diffs can even be compressed. > I believe this is exactly what svn does. It certainly keeps a copy of the > last-committed (or updated-to) version in every working copy, along with the > version being worked on. This allows it to do various things while offline. Exactly. It keeps the "base revision" (they call it "text base"). This is the revision your local files are based on. You can see which revision this is with "svn st -v" When I was lurking at svn mailing lists years ago (it was around svn-0.17 or something), once a month came the request either to remove the text base completely or to compress it. I bet the requests are still beeing made once a month. > No, but I believe this is how CVS works - SVN on the other hand only > transmits the diffs in either direction, [ ... ] Yupp... > > If you don't keep a repository locally then one way or another you will > > have to obtain a copy of the old version in order to just sync changes > > somehow.. > This being, I believe, one of the main reasons SVN does keep a copy (of the > latest-known-committed version) locally. svn-1.4 includes a svnsync utility. This is meant to replicate/sync repositories. Form the description on subversion's homepage I deduce that svnsync is just a reimplementation of svk. But I haven't done a look at it yet, so I can be wrong. > Some other good reasons are things SVN can then do offline, e.g. > - generating diffs (what exactly did I change this time?) > - reverting a file (nono, that's no good, let me start over...) > > It can then also more easily update the working copy with new code from the > repository, by seeing local diffs vs diffs in the repository. > > It only keeps one previous version in the working copy though, so for > comparing with or reverting to earlier versions, it must still be online. AFAICS, with svn-1.4, this is no longer true. You can keep a local copy of the repos at the cost of disk space. You do your ordinary work against this local copy. When you are at home, you sync the local repos against the main repos with svnsync. Too bad you can't attach 1.8 inch USB disks to Neo due to USB beeing non-powered :-( > > Its an interesting thought.. does anyone know for sure if SVN sends back > > only the changes and how it does that if it doesn't fetch the previous > > version for comparison? SVN have even more selling points: - Can be served by apache with SSL, so you get encryption+authentication - Can use apache's mod_deflate to compress the diffs before sending them - You can setup apache so that you can browse/download newest revision with ordinary web-browser. _______________________________________________ OpenMoko community mailing list community@lists.openmoko.org http://lists.openmoko.org/cgi-bin/mailman/listinfo/community