Re: Checkin/checkout via 'sneakernet'

> 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