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: Greg Chicares
Subject: Re: [lmi] Converting a proprietary svn repository to git
Date: Sat, 27 Feb 2016 21:27:51 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Icedove/38.5.0

On 2016-02-27 20:28, Vadim Zeitlin wrote:
> On Sat, 27 Feb 2016 18:33:22 +0000 Greg Chicares <address@hidden> wrote:
> 
> GC> On 2016-02-27 15:23, Vadim Zeitlin wrote:
> GC> > On Sat, 27 Feb 2016 02:11:51 +0000 Greg Chicares <address@hidden> wrote:
> GC> [...]
> GC> > GC> Let's compare the '--no-metadata' and '--msg-filter 
> msgfilter-rev2sha' results:
> GC> > ...
> GC> > GC> All the differences are in .git/ , and they seem to be just binary;
> GC> > GC> the contents of {data/ src/ test/} are identical. I think I can 
> conclude
> GC> > GC> that for this migration 'msgfilter-rev2sha' isn't beneficial.
> GC> > 
> GC> >  Err, I am not sure how do you make this conclusion, even if the result 
> may
> GC> > well be true.
> GC> 
> GC> Because I thought the script's job was to rewrite repository contents
> GC> to refer to git hashes rather than svn revision numbers--and it made
> GC> no such changes. But it seems I misunderstood completely:
> 
>  It looks like I don't explain it well enough in my guide, but the purpose
> of this script is to rewrite the references to the existing svn revisions
> in the repository history. I.e. if you had a commit message "Update
> personal data after the changes of r12345" in your svn repository, it now
> becomes "Update personal data after the changes of abcdef" where the Git
> SHA-1 "abcdef" corresponds to Subversion r12345.

Okay...but the explanation in your guide seems perfectly clear: it does
exactly what I understood it to do.

Or almost. It comes down to a question of what is data and what is metadata.

I think of commit messages as data: the contents of a file whose name is
'ChangeLog'. Now, 'ChangeLog' is just a regular file like any 'alert.hpp';
it just happens to be the unique file where all commit messages go. So, if
your script rewrites commit messages, then I assumed it must rewrite only
'ChangeLog'. And, when I observed no change in the contents of 'ChangeLog'
or of any other file, I concluded that it had no effect: that the problems
it solves were not present in this particular repository.

However, commit messages are fundamentally metadata; it is simply my
practice to write them in a file named 'ChangeLog'. The facet of commit
messages that the script modifies is the essential metadata facet, not the
incidental change-log-contents facet. Yet to me as a cvs and svn user, the
"essential" is the useless--because the commands are so slow, at least if
I don't go to the extra trouble of making a local repository just for such
tasks--and the useless becomes the ignored, then the forgotten, and then
ultimately (in my mental model) the nonexistent. And the "incidental"
replaces it as the one and only (useful) reality, and thus the only one
the script could intend to affect.

BTW, you were right all along about git. It really is vastly better, even
for someone like me who doesn't use branches.

>  IOW this script takes care of one of the drawbacks mentioned in git svn
> documentation by updating the existing revision references which would
> become out of date. It still doesn't replace them in the bug tracker and
> the mailing list archives, this will have to wait for the next version, to
> be written in Perl 6.

When the time comes to do that, don't forget 'ChangeLog'.




reply via email to

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