Question on (my) workflow migration svn -> git

David Wolfskill david at catwhisker.org
Sat Sep 26 02:09:56 UTC 2020


On Fri, Sep 25, 2020 at 07:23:07PM +0200, Ulrich Spörlein wrote:
> On Thu, Sep 24, 2020 at 10:53 PM Brooks Davis <brooks at freebsd.org> wrote:
> ...
> > I don't see a good way to keep a bare repo on the laptop.
> >
> > I hope this give you an idea where to start.
> 
> Why not a bare repo same as with the svnsync copies before?
> 
> On each machine (doesn't matter if connected or not) he could:
> 
> git clone --bare https://.../{src,ports}
> 
> and "git fetch --all --prune" (or some combination) whenever internet
> connectivity exists. Then it's easy enough to clone from that local
> copy for the various branches,

I have a local copy of the freebsd-cgit-beta from around 01 September
(that I had picked up for experimentation).

So I tried making a bare clone of it:

* cd <some scratch area>
* git clone --bare file:///repo/git/freebsd/freebsd-cgit-beta

(which created freebsd-cgit-beta.git/).

The original was ~2.5 GB; the bare clone, ~1.2 GB.

Them on another file system:

* cd <another scratch area>
* git clone file:///bkp/tmp/git/freebsd-cgit-beta.git head

which seems to have worked; result is ~2.5 GB.

Then (after poking aoround a bit in the output of `git help clone`):

* git clone -b stable/12 --single-branch file:///bkp/tmp/git/freebsd-cgit-beta.git stable_12

While that had the benefit of terminating quickly, the resulting
messages:

Cloning into 'stable_12'...
warning: Could not find remote branch stable/12 to clone.
fatal: Remote branch stable/12 not found in upstream origin
fatal: the remote end hung up unexpectedly

were not encouraging. :-}

(Using "origin/stable/12" made only cosmetic differences.)

So I tried:

* git clone  file:///bkp/tmp/git/freebsd-cgit-beta.git stable_12

which did the same thing the "head" version did (but called it by a
different name).  I then tried:

* cd stable_12/
* git branch | cat

For which the response was:
* main

Then, I tried this:
* git checkout stable/12

and was informed:

error: pathspec 'stable/12' did not match any file(s) known to git

Hmm..

> but it's obviously suboptimal. I

Err..  other than the apparent pilot-error(s) I made up there... why?
(It's not "obvious" to me: I don't know; that's why I'm asking.)

> recommend to read `man git-worktree`. From those bare repos, he could
> check out both stable/12 and head to some arbitrary location and keep
> them updated with ... um git pull I believe.

OK; so I looked a bit at `git help worktree`, then (from within the
bare repo) ran:

* git worktree add ~/tmp/git/head head
fatal: invalid reference: head

OK; fine.
* git worktree add ~/tmp/git/head main
Preparing worktree (checking out 'main')
Updating files: 100% (81780/81780), done.
HEAD is now at d4e0ac52cc2 sh: Write absolute path in command -vV and type

That "head" worktree consumes ~1/3 GB.

So, then:

git worktree add ~/tmp/git/stable_12 stable/12
fatal: invalid reference: stable/12

Yeah, I kinda expected that one.  Not clear on how to acocmplish a
checkout of stable/12 from the bare repo, though.

> so for svn switch, look at a bare clone + multiple worktrees (if you
> need just a single worktree, then don't do the bare repo, obviously).

I'm not too fussed about that part just yet.

> I also assume that your combination of svnsync + rsync was only due to
> speed, yes?

No.

I had been given to understand that an svn repo created by svnsync
maintains a record of the "parent" repo, so running svnsync subsequent
to intialization will "phone home" to the "parent."

For times when I was away from home, it would not be feasible for my
laptop to svnsync back to my home build machine.  By using rsync for the
local mirroring, I also mirrored that "parent repo" information, so
svnsync, when run on my laptop, (correctly) "phoned home" to
svn.freebsd.org.

(And yes, prior to the switch to svn, I was using CVSup to mirror the
CVS repos.)

> You can ignore all that and always pull directly from the
> cgit.freebsd.org host or whatever the final URL will be. The savings
> in bandwidth are not worth it to do something else, but you can of
> course `git remote add ...` on your laptop and fetch first from the
> local clone and then from the internet.

For my use case, it is important to me to keep my local private
mirrors as close as possible to "the same" (as one another) except
for the defined periods during which they are being updated.

The way I have had things set up, the vast bulk of the day, the repos,
the working copies, and the running systems are all in sync with one
another.  Should I have occasion to point out an issue, it is easy for
me to cite SVN revision numbers as appropriate, and thus make it
somewhat easier for someone else to have a reasonable shot at trying to
reproduce the issue(s).

(This is also tied into why I made a local modification to newvers.sh,
to record the latest commit to the branch in question -- not just the
latest commit to the repo.  But that's going away....)

> In short, the svnsync crutch is no longer needed, git can do that all
> natively and will be so much faster doing it, to boot. But, you'll
> need to read up on clones, fetches, bare repos, worktrees and other
> stuff.
> 
> Happy to answer more questions, once you've played around a bit to get
> a feel for what's possible.

Thank you; I appreciate it.

While I use git at work, it's rather far removed from my own use case
(described earlier in this thread).

> Cheers
> Uli
> ...

Peace,
david
-- 
David H. Wolfskill				david at catwhisker.org
"We aren't hiding. We are named witnesses to Donald Trump's unfitness for
office." -- Miles Taylor, former chief of staff to former DHS Secretary
Kirstjen Nielsen

See http://www.catwhisker.org/~david/publickey.gpg for my public key.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 618 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-git/attachments/20200925/6f393177/attachment.sig>


More information about the freebsd-git mailing list