> 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)
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).
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
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
So really it's a case of:
a) moving the diffing routines from client process to the server process
b) altering the diffing process to get the working copy across the
network and pristine copy from the repository
c) altering the commit routines to recieve the differences from and
local process instead of over the network
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?
Bearing in mind I don't know the code too well (yet). Where is the can
of worms kept?
tOnY
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 11 19:55:59 2003