Re: Checkin/checkout via 'sneakernet'

On Thu, 13 Nov 2003 11:39:28 -0600, Ben Collins-Sussman
<sussman@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