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. _______________________________________________ Ros-dev mailing list Ros-dev@reactos.org http://www.reactos.org/mailman/listinfo/ros-dev
