You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by John Allsup <al...@for.mat.bham.ac.uk> on 2003/11/12 11:34:04 UTC
Checkin/checkout via 'sneakernet'
Hi,
I've come up against a situation (a couple of years back) where this sort
of thing
would have been nice. (I coded up a _very_ bad implementation in PERL that
was good
enough for my needs at the time. I concluded that I didn't know enough
about doing
version control and stuff properly.)
Basically this occurs when e.g. you're going home for Christmas, want to
get work
done but don't have internet access, just a PC. (Assume that network
connection
is impossible.)
What I'd like to be able to do is:
We have two pc's, which I'll call D (for disconnected) and N (for
networked).
I want to be able to work from D, but retain versioning during this time,
(though only be able to _use_ versioning after stuff is checked back in.)
So, I'd like to be able to sit down at N, check out some project and
copy the
'checkout' to a zipdisk. I'd then like to be able to sit down at D,
insert the
zip disk, and then complete the checkout to D.
Working at D, I want to have a 'journal' of 'checkin's which I can copy
back
to the zip disk, take to N, sit down and then 'batch checking' as if the
checkins
done at D really went directly to the server.
With respect to the above:
* What are the issues?
* What is feasible?
* What is easily hacked into the client? (clearly no server hacking is
allowed)
* What is possible already?
* What is not possible? (And why?)
* What is not worth the effort? (please don't just say 'the above')
Thanks,
John.
--
John Allsup
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by John Allsup <al...@for.mat.bham.ac.uk>.
> John,
> I wonder if a zip disk is 1) big enough 2) fast enough 3) reliable
> enough (should go as first question perhaps) to hold your repos. Or
> a copy of it. Of course this assumes that you are the only one ever
> accessing the repos. The other option would be about what you are
> currently doing: keep a working copy on the zip disk, work on it on
> the disconnected machine, later back at the networked box
> (update and) commit your stuff. If you need/want to keep specific
> changes in different commits, well, then this is not possible. Or
> with manual work only: in TortoiseSVN e.g. you can select which
> files go into a commit.
>
> Dunno if this is of any help for you.
>
> Jan Hendrik
Jan,
Thanks (to the people on the list who replied) for the conversation. The
problem to
me isn't practical at present. It was practical one at some point in the
past, my
solution involved a perl script that copied e.g. hello.c to
1234da7e.machineName.hello.c
in a separate directory and gzipped it. I then simply wrote what logic I
wanted on top
of that, so that a script could simply run through the files building up
an approximate
tree of changes if one was required. Basically, the repository
architecture did just
enough to get just enough of the information 'there' and then I wrote what
I needed.
I didn't like the how my attempt at the checkin/checkout/management stuff
worked.
I'm thinking of using Subversion as a starting point to writing what I
want and
'doing it right this time, once and for all.' (Here right really means so
that I
can use the system without perpetually thinking about how to make it
better...
that makes working with such a system difficult... so I ended up not using
it.)
I think I'll get subversion up and running, start
hacking and playing and try to figure out _exactly_ what I do want, and
also
what I don't. If I get some code, possibly and probably a dirty hack at
first,
I'll use that to demonstrate what I am talking about. The reason I was
suggesting
this sort of thing is that, to me at least, it seem like it should be
trivial to
implement given a good enough single repository foundation. Chasing up
easy to
hack ideas like this (and only bothering to write code if you can see the
hack
easily) allows one to start with the single repository model of e.g.
Subversion
and to explore the middle ground between single and distributed
repositories (i.e.
how far one can easily masquerade as the other.) Doing this with a
working system
like Subversion allows you to 'eat your own dogfood' whilst going about it.
Clearly the idea in my head is not 'ripe' enough for discussion yet, so
I'll leave
it for now. My main priority is writing up my thesis. I'm getting a
Linux box in to
complement our (postgraduate) office PC (my current box is 160 miles away
and I didn't want the
distraction even to be available whilst I started figuring out how I
wanted to write
up the thesis.)
Cheers,
John
--
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
Re: Checkin/checkout via 'sneakernet'
Posted by Paul Gross <p-...@northwestern.edu>.
What about just keeping the whole repository on the zip disk, provided
it doesn't get too large. Then, wherever you go, you have the
repository, so you can commit to it and update from it. As a safety
measure, you could have backup scripts that backup the repository
whenever it is connected to one of your computers. Am I missing
something that makes this solution unfeasible?
Paul Gross
paul@grosss.net
Jan Hendrik wrote:
>Concerning Re: Checkin/checkout via 'sneakerne
>John Allsup wrote on 13 Nov 2003, 15:18, at least in part:
>
>
>
>>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.
>>
>>
>
>John,
>I wonder if a zip disk is 1) big enough 2) fast enough 3) reliable
>enough (should go as first question perhaps) to hold your repos. Or
>a copy of it. Of course this assumes that you are the only one ever
>accessing the repos. The other option would be about what you are
>currently doing: keep a working copy on the zip disk, work on it on
>the disconnected machine, later back at the networked box
>(update and) commit your stuff. If you need/want to keep specific
>changes in different commits, well, then this is not possible. Or
>with manual work only: in TortoiseSVN e.g. you can select which
>files go into a commit.
>
>Dunno if this is of any help for you.
>
>Jan Hendrik
>
>---------------------------------------
>Freedom quote:
>
> Socialism in general has a record of failure so blatant
> that only an intellectual could ignore or evade it.
> -- Thomas Sowell
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
>For additional commands, e-mail: users-help@subversion.tigris.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: Checkin/checkout via 'sneakerne
John Allsup wrote on 13 Nov 2003, 15:18, at least in part:
> 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.
John,
I wonder if a zip disk is 1) big enough 2) fast enough 3) reliable
enough (should go as first question perhaps) to hold your repos. Or
a copy of it. Of course this assumes that you are the only one ever
accessing the repos. The other option would be about what you are
currently doing: keep a working copy on the zip disk, work on it on
the disconnected machine, later back at the networked box
(update and) commit your stuff. If you need/want to keep specific
changes in different commits, well, then this is not possible. Or
with manual work only: in TortoiseSVN e.g. you can select which
files go into a commit.
Dunno if this is of any help for you.
Jan Hendrik
---------------------------------------
Freedom quote:
Socialism in general has a record of failure so blatant
that only an intellectual could ignore or evade it.
-- Thomas Sowell
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Files <fi...@poetryunlimited.com>.
Jan Hendrik said:
> Here's what Shamim Islam posted short time ago:
>
>> http://svn.elixus.org/repos/member/clkao/svk/
>>
>> It rides on top of svn.
>
> As I understand it is not the real svk but a superset or something
> resembling it on the base of svn. But maybe worth a try or as
> source for the "real" stuff ...
Dude, you're right. It's not the real svn. But you can use svn to check it out
and compile. It sits on top of svn and does the decentralization part. :)
Allows you to take aa copy of the repository, do your thing and then send the
changes after a while to a different repository. At least that's how it was
explained to me.
clkao is the dude working on it.
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Jan Hendrik <ja...@bigfoot.com>.
Concerning Re: Checkin/checkout via 'sneakerne
Andreas Jellinghaus wrote on 12 Nov 2003, 17:43, at least in part:
> On Wed, 2003-11-12 at 17:27, Ben Collins-Sussman wrote:
> > So my recommendation is: go try out arch or svk.
>
> neither freshmeat nor sf.net knows about it, and google
> returns tons on stuff with three letter acronyms.
> do you know the url of it's webpage?
Here's what Shamin Islam posted short time ago:
> http://svn.elixus.org/repos/member/clkao/svk/
>
> It rides on top of svn.
As I understand it is not the real svk but a superset or something
resembling it on the base of svn. But maybe worth a try or as
source for the "real" stuff ...
Jan Hendrik
---------------------------------------
Freedom quote:
It is not my intention to do away with government.
It is rather to make it work -- work with us, not over us;
stand by our side, not ride on our back.
Government can and must provide opportunity, not smother it;
foster productivity, not stifle it.
-- Ronald Reagan,
First Inaugural Address, January 20, 1981
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Christian Sauer <ch...@endrun.org>.
Andreas Jellinghaus said:
> On Wed, 2003-11-12 at 17:27, Ben Collins-Sussman wrote:
>> So my recommendation is: go try out arch or svk.
>
> neither freshmeat nor sf.net knows about it, and google
> returns tons on stuff with three letter acronyms.
> do you know the url of it's webpage?
>
> Thanks, Andreas
>
google for "Tom Lord" arch
http://www.gnu.org/software/gnu-arch/
-Christian
--
God put me on earth to accomplish a certain number of things.
Right now I am so far behind I will never die.
-Bill Waterson, Calvin and Hobbes
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Andreas Jellinghaus <aj...@dungeon.inka.de>.
On Wed, 2003-11-12 at 17:27, Ben Collins-Sussman wrote:
> So my recommendation is: go try out arch or svk.
neither freshmeat nor sf.net knows about it, and google
returns tons on stuff with three letter acronyms.
do you know the url of it's webpage?
Thanks, Andreas
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by Files <fi...@poetryunlimited.com>.
I have your solution. Use a floppy w/ a copy of the latest thesis checked out
on it. Sounds like what you're trying to do.
Or are you trying to do what I did at work at one time, where we had a central
PVCS repository for handling the main gold development trunk and RCS for
localized repository maintenance in each developers work area.
I'm not sure what you're getting at. SVK is very close to this last.
Guess we're all just not understanding your situation.
--
Shamim Islam
BA BS
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by John Allsup <al...@for.mat.bham.ac.uk>.
On Thu, 13 Nov 2003 11:39:28 -0600, Ben Collins-Sussman
<su...@collab.net> wrote:
> On Thu, 2003-11-13 at 11:30, John Allsup wrote:
>
>> 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.
> Where does the change go when its committed?
Basically, subversion (except the network layer) will view the change as
if it
came from an actual commit. (How one works in the 'date discrepancy' may
or
may not be a problem: it all depends on the underlying architecture of
subversion.
Can you (if permitted: per repository setting or something) do a
retroactive
commit (e.g. so that a checkin can be done now, but changing the repository
as if the changes happened a week ago?)
I think it's probably an idea to stop this discussion for now. I'll have
a more
detailed read into how subversion works right now.
> You want your working copy to believe it has committed to 'something'.
Yes. A simple 'journal' with a little automatic delta compression.
It may have a better name, but I'll call it a journal (basically, you
keep appending entries to it.) Call a commit from the pov of the
disconnected PC
a j-commit. (i.e. a commit to the journal.) Call a commit from that
journal
to the actual subversion server an f-commit (finalised commit.)
These are the rules:
* You checkout once on the disconnected PC;
* After checking out, you can modify and j-commit as many times as you
like;
* When you want to get the stuff back to the subversion server, you
finalise;
* You carry the finalised journal to the networked PC and do an f-commit;
* Subversion must allow only one f-commit per 'disconnected checkout'.
* Once you've finalised, you need to do a 'disconnected checkout' in order
to do some more 'disconnected editing'
There is enough information in a finalised journal to figure out what is
going on.
There is enough information in the repository to do an (if necessary
history
rewriting) commit. The main question is practical feasiblity (rather than
'theoretical' feasibility.)
Note that, on the disconnected machine, the sequence can go e.g.:
checkout, modify, j-commit, modify, j-commit, modify, j-commit,
finalise, f-commit.
Or
checkout, modify, j-commit, finalise, f-commit.
But you cannot do e.g.
checkout, modify, j-commit, modify, j-commit, checkout (result of the
commit), modify, etc.
Only ONE checkout, at the start of the editing sequence is allowed. (I'm
not sure at
present of the best way to enforce such a policy, but it can't be too
hard. Either that
or it's impossible, I can't see there being an in-between on this matter.)
> You then make more changes in the working copy, and commit to
> 'something' again. You repeat this process a few times.
> Then later on, you want 'something' to commit all the saved-up changes
> to the true repository.
> So whatever 'something' is, it's not just a simple capacitor.
No. It has a rudimentary knowledge of how successive commits interact.
Theoretically, it needn't even have this. The reason is that only
one checkout per disconnected editing session, but as many commits
as you like. When you j-commit on the disconnected machine, you cannot
see the results without a carry-data, f-commit, disconnected-checkout
round-trip (where disconnected-checkout covers the checkout to the
networked
PC, carrying it, and the 'virtual' checkout to the disconnected machine.)
> It needs to be smart.
Not by much, given enforcement of the one-checkout rule.
> It has to be able to collect a bunch of changesets and
> manage them as real objects.
No. The one-checkout rule described above (if I'm correct) means that most
of
the work is done by the subversion server. The journal part needs to know
very
little (in practice, only a little more than delta compression and rename
tracking:
it doesn't have to figure out full consequences, only consolidate
successive
commits.)
Also, if I'm right, all you really need for the journal is some of the
checking
in code from subversion (with subtle modifications.)
In short: what I'm suggesting (the simplifying factor) is that, on the
disconnected
PC, you can't just 'commit and see the results' like you would on the
connected PC.
If you can live without that... (basically, rolling back and stuff will be
done after
the commit has happened, and from a networked client, not the disconnected
one. The
disconnected client just allows you to carry on working in some reasonable
way given
the absence of the possiblity of a direction network connection in the
future from
where you have to work.) This is what (if I'm right) removes the need for
most of
the intelligence you're suggesting is necessary.
John.
--
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
Re: Checkin/checkout via 'sneakernet'
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-11-13 at 11:30, John Allsup wrote:
> 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.
Where does the change go when its committed?
You want your working copy to believe it has committed to 'something'.
You then make more changes in the working copy, and commit to
'something' again. You repeat this process a few times.
Then later on, you want 'something' to commit all the saved-up changes
to the true repository.
So whatever 'something' is, it's not just a simple capacitor. It needs
to be smart. It has to be able to collect a bunch of changesets and
manage them as real objects. It also needs to understand the working
copy that they came from, and the repository to which they're destined.
Hey... look... 'something' sure sounds a whole lot like a distributed
repository! :-)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by John Allsup <al...@for.mat.bham.ac.uk>.
On Thu, 13 Nov 2003 09:45:00 -0600, Ben Collins-Sussman
<su...@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
Re: Checkin/checkout via 'sneakernet'
Posted by Ben Collins-Sussman <su...@collab.net>.
On Thu, 2003-11-13 at 09:18, John Allsup wrote:
> On Wed, 12 Nov 2003 10:27:31 -0600, Ben Collins-Sussman
> <su...@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.
Maybe I'm wrong, though.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Checkin/checkout via 'sneakernet'
Posted by John Allsup <al...@for.mat.bham.ac.uk>.
On Wed, 12 Nov 2003 10:27:31 -0600, Ben Collins-Sussman
<su...@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.
> The theory is that every user has a personal repository. They can
> commit to it locally, and later on, have their own repository exchange
> changesets with other repositories by "pushing" and "pulling" them at
> will. The repositories can be set up in any sort of hierarchy you want,
> and each repository remembers which changesets it already has.
Far too much decentralisation for what I want. I just want to have a
non-TCP/IP
network connection with indefinate latency. How difficult is this? I'm
considering
having a go myself once I've got my work PC with Linux set up to type my
thesis
into.
> So my recommendation is: go try out arch or svk.
Already had a look at arch: didn't 'feel right'. For me that is
important: it tends to tell me how easily I will be able to 'scratch my
itches' with
simple intuitive solutions (when you see the problem, phrase it to
yourself, the solution
appears in your head immediately and you just stick it into the system...
I like that...)
Not being into serious developing of version systems such as subversion,
the easy
intuitive 'itch scratching' is what I'll be doing with it.
John.
--
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
Re: Checkin/checkout via 'sneakernet'
Posted by Ben Collins-Sussman <su...@collab.net>.
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.
The theory is that every user has a personal repository. They can
commit to it locally, and later on, have their own repository exchange
changesets with other repositories by "pushing" and "pulling" them at
will. The repositories can be set up in any sort of hierarchy you want,
and each repository remembers which changesets it already has.
So my recommendation is: go try out arch or svk.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org