[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Checkin/checkout via 'sneakernet'

From: John Allsup <allsupj_at_for.mat.bham.ac.uk>
Date: 2003-11-13 18:30:19 CET

On Thu, 13 Nov 2003 09:45:00 -0600, Ben Collins-Sussman
<sussman@collab.net> wrote:

>> > You want the sort of model that bitkeeper, svk, or arch uses. It's a
>> > 'decentralized repositories' design, rather than CVS or SVN's
>> > centralized-repository design.
>> Thanks for the suggestion, but I do _not_ want full _decentralised_
>> repositaries.
>> I want one single repository, and a small less-than-repository
>> client-thingy to handle the little bit of decentralised repository
>> design that I want. Basically I just want to have the ability to check
>> in via a non-TCP/IP network connection with indefinate latency. Going
>> to bitkeeper or arch is overkill.
> I personally can't envision a design for this halfway-system. In my
> mind, there's either 1 repository or an infinite number. I can't think
> of a design for exactly 2 repositories; the result is always equivalent
> to an infinite number of them.
In what I am suggesting, there is _still_ one repository. If you're having
trouble picturing what I'm suggesting: imagine that the TCP/IP connection
done via the RFC1149 (i.e. pigeon post.) Imagine that there is no set plan
as to when you let the pigeons fly. Then forget about the various bits
of the TCP/IP packet structure that aren't relevant to the versioning
Then hack in an 'input' that bypasses the network layer in subversion,
hack in an 'output' that bypasses the network layer. That sort of thing.
(This is obviously an attempt at an abstract picture: I'm trying to see
the implementation details first, then pull back and see what is

Another way of picturing what's going on is the difference between e.g.
sound from e.g. M$ media player though the sound card, and using the
driver hack to capture the file to the hard drive, carry it to another PC,
play the sound there. Do similarly with a microphone (just going in the
direction.) That sort of thing.

Basically it's a kind of disconnected operation which doesn't require the
'work PC' to be actually physically connected at all. Another PC is doing
'being physically connected' thing for it.

That's what I'm thinking of. I don't know about the implementation details
of subversion enough to look into the feasibility of what I'm suggesting: I
don't yet have the PC (that I'm thinking of doing this on) here in

> Maybe I'm wrong, though.
Maybe, maybe not. I'll keep playing with the idea (and reading a little
more about
how versioning systems are dreamt up.) If I come up with something that's
satisfactory with regards to what I want, and satisfactorially easy to
implement given
what's already there, I'll give it a go.


(*) The basic philosophy is this:
1. think of what is ideal;
2. think about what is possible (wrt the above);
3. think about what is feasible (wrt the above);
4. think about what is feasible (wrt the above, with a slightly saner
definition of 'feasible');
5. think about what is easily implementable given what is available;
6. go back and analyse how the stuff in 3,4,5 relate to 1,2.
Then design it, code it, test it and see how it runs.

p.s. Clearly I'm a think first, implement later person. So far as trying
code first, then think thing: for me it just doesn't work very well.

John Allsup
   blog: http://johns-thoughts.blogspot.com
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Nov 13 18:35:16 2003

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.