25 Feb
2016
25 Feb
'16
9:45 a.m.
Hi all,
want to share some thoughts and experiences regarding a VCS migration.
On 2016-02-25 07:49, Neal Gompa wrote:
The poor usability of Git on non-*nix platforms is one
of the reasons
why I'm still a huge fan of Mercurial. Also, the SVN-like CLI workflow
means that's it's less disruptive than moving to Git. There's also a
fantastic guide on how to get started with Mercurial[0].
First of all, I'm also
a big fan of Mercurial for the exact same
reasons. And perhaps I'd also add that I find that Git often lives up to
its name (e.g. when I say `git <command> --help` I do *NOT* want to be
dropped into a man page but rather see a concise description of options).
That being said, Mercurial and Git can interoperate
with each other
fairly well. If you choose to have a Git server, then Mercurial can
talk to it through hg-git[1]. If you choose to have a Mercurial
server, then Git can talk to it through git-remote-hg[2].
In all fairness hg-git
broke for me _consistently_ in the past. I would
not consider it reliable or recommend it to anyone for anything but the
simplest/smallest of repositories. Sometimes it was the "connection"
between the two repos that broke or that some idiom of either side was
not understood by the other.
However, Mercurial has better support for natively
working in Windows,
SourceTree (by the makers of Bitbucket) provides a fairly good
user
experience on Windows, but you often still need to drop to a command
prompt for certain advanced operations. But I've had this experience for
both Git and Mercurial.
and tends to handle the differences of platforms a
whole lot better
than Git does. My experience with importing and contributing to SVN
based projects tends to be better with Mercurial than Git,
Not sure what repos you
have imported and by what means and how you
verified that the whole thing was a valid duplicate. However, I can tell
you from my experience that I have not found a single repo exceeding a
few dozen revisions that could be converted without losses using the
import tools provided by Hg _or_ Git communities.
A lot of prerequisites have to be met to allow for a migration to
produce a proper valid duplicate on the other version control system.
For SVN this means usually that the convention(!) of having top-level
folders trunk, branches and tags need to be true for the *whole*
revision range to be converted. So if you started without this
convention and then introduced it - bad luck. Same if you had certain
accidents on the SVN side. Same if you introduced another project as
top-level folder and later merged it.
All these "kinks" in the revision history are bound to throw off these
automated import tools. I do know that some of them employ heuristics to
"take care" of certain accidents. And of course one can opt to ignore
the visible warnings. But most of those instances would really have to
be reviewed by a human and require some kind of decision. So automatic
handling leads to loss of information.
Essentially it depends on how truthful you want your copy to be. If you
can do with something that "just works" -- and "Git from now on, but SVN
if you want to rebuild historic revisions" -- then you can probably use
the import tools provided by the Git community. If you need more, they
just won't cut it.
simply because the SVN data maps better in Mercurial.
Sorry to say, but this is simply untrue. There are plenty of things in
Subversion that do not at all map to anything in either DVCS. Starting
with the concept of tags and branches as folders. Same for empty
folders. And in my conversions (about a dozen which I saw through to the
end) I have often ended up with cases where Git as the target VCS would
have been a better match than Mercurial. It really depends *if* you want
a high-quality conversion.
I have worked with reposurgeon for nearly three years and it's the only
comprehensive tool, I know of, to achieve lossless copies of a repo in
another version control system. It even comes with a companion tool to
verify the results and best of all it is a maintained FLOSS project
(hosted on a Gitlab instance, btw). I can help if you choose to go this
route to have a high-quality conversion using reposurgeon. And AFAIK ESR
(the author) himself will also happily help out FLOSS projects like
ReactOS when you run into trouble. He did the conversion of Emacs to
Git, btw.
There are very nice FOSS tools out there for providing
an excellent
development experience, such as Phabricator[4] and GitLab[5] for
self-hosted environments. If you really want to move to a Git based
hosted platform, GitLab.com offers free hosting[6], and there's also
BitBucket[7] for either Mercurial or Git.
Let me add Kallithea, although the
aforementioned ones come with many
additional features. In particular Phabricator comes with a code review
platform which is also used by the LLVM project. Here's an example which
shows many of the features Phabricator offers:
http://reviews.llvm.org/D11532
Last but not least: I think it's also worthwhile to point out that the
LLVM projects are also still using SVN and they fare well with it. Those
wanting to use Git, can use a Git mirror and git-svn marks are used to
interoperate. So it is already possible to use Git without completely
migrating.
That said, take your time. Especially if you intend to take the SVN repo
down after migration.
// Oliver
PS: still it can be said that *if* you opt for a high-quality conversion
and want to migrate to another DVCS later on, the effort required will
be considerably lower than going from CVS or SVN _to_ any DVCS initially.