lmi
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [lmi] Converting a proprietary svn repository to git


From: Vadim Zeitlin
Subject: Re: [lmi] Converting a proprietary svn repository to git
Date: Mon, 29 Feb 2016 19:40:12 +0100

On Mon, 29 Feb 2016 18:32:56 +0000 Greg Chicares <address@hidden> wrote:

GC> On 2016-02-26 02:01, Vadim Zeitlin wrote:
GC> [...]
GC> >  The next step would be to "git push --all" to some bare repository and
GC> > then clone it from somewhere else and verify that everything looks good.
GC> 
GC> Once I get past the obstacle reported in my last email, which of these
GC> git repositories do we use going forward? We have
GC>   (A) the one cloned directly from svn;
GC>   (B) the new bare repository to which we pushed (A); and
GC>   (C) the new non-bare repository cloned from (B).
GC> I think the answer is that
GC>  - (A) should be discarded
GC>  - if we were going to establish a central server, we might place (B)
GC>    there; but we aren't going to do that, so (B) should be discarded

 I thought it could still be useful to maintain some "reference" repository
even if it's not a "central" one, so I thought you'd be using (B) as it.

GC>  - thus, (C) is what we should use from now on, and (A) and (B) should
GC>    both be thrown away.
GC> Is that a reasonable way to proceed?

 Yes, but if you don't need a bare repository at all, you could just clone
(C) directly from (A), there is no real need to create (B) at all.

GC> BTW, what was the purpose of pushing to a bare repository and then
GC> cloning it? Was it just to test the validity of the repository that
GC> was cloned directly from svn? Or was it to rinse out any vestiges
GC> of its link to svn, so that no one can accidentally try to use it as
GC> an svn gateway?

 The latter was the reason not to use (A) directly, as you have seen it
contains git-svn pseudo-remotes which are not quite the same as the real
git remotes and can be confusing. A bare repository is useful if you want
to push to it (you can also push to non-bare repositories but you need to
take more care with it and you still shouldn't (and can't, with the recent
git versions) to push into the currently checked out branch, so you may
need to temporarily switch branches before pushing), so if you don't plan
to do this at all, you don't need. In practice, I find it nice to have a
bare repository if only as an extra backup (notice that a bare repository
takes less space than a normal one because there is no working directory,
so it should be definitely preferred for backups).

 Hope this clarifies things,
VZ

reply via email to

[Prev in Thread] Current Thread [Next in Thread]