Tony Mee wrote:
>>Of course it can:
>> svn checkout file:///local/path/to/repository
>>We could hardly call ourselves a CVS replacement without that
>>ability. :-)
>>
>>
>Firstly, thank you Ben... I'll give that a try.
>
>Mmm... Aside from the clear appeal of seeing Michael Price dance a jig
>in his no doubt lovely purple wig. It's the multiplication thing...
>
>I have a file server on which my repository is stored (taking up more
>space than the code itself with all the revision info). I also have,
>neglecting offsite users, 15 people locally working on the code. All
>of whom have their home space on my file server. This all seems much
>worse under SVN:
>
>Nightmare A - No version control
> 15 users have their own copies and pass around patches (somehow!)
> = 15 copies
>
>Situation B - CVS
> 1 master (repository) copy (larger than user copies)
> + 15 users have their own copies
> = 16 copies (overhead of 1 admittedly large copy)
>
>Situation C - Subversion
> 1 master (repository) copy (larger than user copies)
> + 15 users have their own copies
> + 15 users have their own pristine copy
> = 31 copies (overhead of more than 200%, ouch)
>
Where did you get the >200%? Just comparing the number of copes, 31/16 =
194%. Now, taking into account that the repository is, let's say 10
times the size of a copy, you get 40/25 = 160%. If your repository is
100 times larger (which is more probable, I guess), the factor becomes
130/115 = 113%. Not so unreasonable, right?
>As for bandwidth for local and remote users... As I mentioned earlier,
>are users really updating all the files in a repository at once?
>
>That just ain't going to please my sys op. EVER. Now why should I, as a
>sys op. and hence being the person that is ultimately going to install
>SVN or CVS pick SVN?
>
>---------------------
>
>Now before I stick my neck (or rather coding fingers) out and
>inadvertantly have my head knocked off by a passing truck, could
>somebody that has hacked the code a bit tell me if this is right:
>
>All the diff'ing routines exist, as do all the local file access
>routines (noting Michael Price's comment) and so do routines for
>transfering whole files across the network (for the checkout function).
>
I detect a possible misconception here. We have two kinds of diffs; the
text diffs that you can make patches from, and the binary deltas that
are passed between the server and the client. Those are two completely
different beasts.
The pristine copy in the WC is used for two things:
* To remove the need for network access for some operations (such as
plain "svn diff")
* To enable the client and server to send deltas to each other
instead of fulltext versions.
The pristine copy isn't strictly necessary for either of these.
>Currently:
>
> 1) Client diff's it's pristine and working copy
> 2) Client sends diff's to server
> 3) Server stores the diffs in the repository
>
Not quite:
1. Client constructs a delta between its pristine and working copy
2. Client sends this delta to the server
3. Server reconstructs the client's working copy from the delta (and
the original source, which is already stored on the server)
4. Server stores the fulltext, then creates a reverse delta for the
previous version(s).
>Without the pristine copy:
>
> 1) Client sends working copy to the server
> 2) Server diffs what it gets with the pristine (repository) copy
> 3) Server stores the diffs in the repository
>
The client can just send the fulltext to the server; no changes are
necessary on the server side.
However, this is for commit only. The client also uses the pristine copy
as a source for "svn diff", and to help determine if the working copy
differs from the original (we also use timestamps for that, and
checksums, IIRC).
>So really it's a case of:
>a) moving the diffing routines from client process to the server process
>
(You mean deltas.) They're already on the server.
>b) altering the diffing process to get the working copy across the
> network and pristine copy from the repository
>
Not a problem
>c) altering the commit routines to recieve the differences from and
> local process instead of over the network
>
Not a problem.
d) Changing all the client-side routines that need the original to pull
it off the network on demand, and changing the WC metadata to handle this.
>or maybe better put at a case of moving some streams about and the
>position of a process in those streams. Not really any new code?
>
Some new code, especially in the WC management layer. Which hist happens
to be the hairyest part of Subversion. :-)
>Bearing in mind I don't know the code too well (yet). Where is the can
>of worms kept?
>
>
We have a special climate-controlled room that keeps the worms at a low
enough temerature so that they remain dormant. If the temperature varies
by more than +-0.73K, the worms either freeze to death, or eat throught
the CrTiAl alloy of the airlock doors. Dicey.
--
Brane Čibej <brane_at_xbc.nu> http://www.xbc.nu/brane/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 11 20:23:08 2003