On 3/8/2011 4:38 PM, Jeff King wrote:
On Tue, Mar 08, 2011 at 04:20:33PM -0600, Neal Kreitzinger wrote:
Rsync seems like a simpler solution and more accurate solution for
creating a copy of an ecosystem of interrelated git repos colocated on
the same box.
Sure. It is simpler, but not atomic unless you do a multi-stage rsync.
A previous post in the newsgroup states:
If you want your rsync backup to be fine, you need to follow some
ordering. You need to copy the refs first (.git/packed-refs and
.git/refs/), then the loose objects (.git/objects/??/*), and then all
the rest. If files are copied in a different order while some write
operations are performed on the source repository then you may end up
with an incoherent repository."
Would that work?
If you do it in that order, the end result will be a consistent repo.
But during the copy, the refs at the destination will point to objects
you don't have. I don't know if that matters for your case.
We won't be trying to used the "destination" repos during the rsync.
The workflow will be:
(1) I need to test a change to the goldbox change control menu system.
(2) I determine that my testbox "copy" of the change control menu system
has repos that are too out-of-date for a good test, so I run rsync to
make a fresh copy of the goldbox.
(3) After the rsync is finished, I pull over just the branch that
contains my untested change menu scripts. (this is the only git pull i
do from goldbox to testbox.)
(4) I test the changes and see they are good.
(5) I merge the changes into the master branch of the change control
menu non-bare repo on the goldbox. The menu runs from the working tree
so now they are live.
Since I won't be trying to access refs in the "destination" repos via
git commandline or gui while the rsync is running, it sounds like it
will be ok. I can keep people from banging on the testbox. I can't
keep them from banging on the goldbox.
In regards to the working tree of a busy "source" repo, it sounds like
it could end up not matching the index. At the end of the script I
could execute a "git reset --hard && git clean -f" on each non-bare repo
as you suggested. That would be pretty straightforward.
Thanks!
v/r,
Neal
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html