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
is
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
system.
Then hack in an 'input' that bypasses the network layer in subversion,
similarly
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
past
the implementation details first, then pull back and see what is
feasible(*).)
Another way of picturing what's going on is the difference between e.g.
playing
sound from e.g. M$ media player though the sound card, and using the
redirected
driver hack to capture the file to the hard drive, carry it to another PC,
then
play the sound there. Do similarly with a microphone (just going in the
opposite
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
the
'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
Birmingham.
> 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
both
satisfactory with regards to what I want, and satisfactorially easy to
implement given
what's already there, I'll give it a go.
John.
(*) 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
the
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