I am a computer/tech savoy kind of person but when it comes to some of this programming and such I get lost. I know some basic stuff like HTML and VERY VERY little JAVA. I have been given a task that I would LOVE to be able to complete. I am being asked to convert a repository from subversion to mercurial. I have a copy of the repository to try it out with in case something goes wrong I don't want to mess up the actual copy. My question is I do not really know where to start. I found some tutorials online that start off with mirror your subversion well I do not even know how to do that. Could anyone give me a hand with this? Like a click here click there kind of assistance. I am looking forward to learning this as I love to learn new things. Thanks in advance everyone.
A few years ago I used the ConvertExtension described there to convert CSV to hg; and according to the docs Subversion support is even better than the CVS one. I'd suggest starting here or here.
I don't think Java or HTML is going to be of any help here. You do need at least some basic knowledge about version control in general.
I cannot help you with Subversion, unfortunately. I'd suggest starting with this book. It looks like Subversion can connect to a local copy of the repository directly, it is possible that Mercurial will be able to connect this way too, which would mean that you won't need to set up Subversion. You should have means to access the Subversion repository, though, otherwise it would be hard for you to verify the conversion worked well.
My CVS notes probably wouldn't be useful to you, but I can offer some general advice. Be prepared to run the process several times. Create and maintain a documentation/notes of the process and update it after each "run". It would be best if you could create the Mercurial repository and play with it for some time (at least a few days), you'll probably discover a few things that would be nice to handle during the conversion (such as exclude compiled binaries from the new repository, if there are any). Once the Mercurial repository goes live, you practically cannot redo the conversion without a lot of effort. (I, for example, managed to keep only the first line of the multi-line commit messages in the converted repository. A few days later I've discovered how to keep the other lines in the commit messages too, but it was too late, the Mercurial repository was already live and contained new commits.)
I haven't been asked to convert Subversion to Mercurial, but a little over a year ago I was asked to convert CVS to Subversion. My solution - migrate each project individually. The existing projects in the existing version of the product were left in CVS; the new version went into Subversion. Specifically, the 2.1 version remained in CVS. The 2.2 development up until release went into CVS with a final 2-day migration of all projects to Subversion at which point 2.2 went into, and was built from, Subversion. I do have to note that this was not just a repository migration - we also migrated a build process that was part manual (done in a special version of Eclipse) and part automated via Ant into a fully automated build process using Jenkins and Maven. Thus the resulting projects in Subversion were very different from what was in CVS. But the project-at-a-time migration strategy might work for you also.
So you didn't move the history from CVS to Subversion, Peter? That would be an option too, of course.
This reminds me that converting the repository incrementally (project by project) from CVS/Subversion to Mercurial must be well thought out. In Mercurial (and other distributed systems, such as git), the repository cannot be split into parts, or merged from various parts, at least not easily. There is a subrepository functionality which allows to manage projects that depend on another projects (such as a library shared by several other applications), but I don't have experience with that yet. I decided not to go into it before gaining some experience with basic Mercurial. We now have two applications and a shared library in one Mercurial repository. I suppose we'll split it into three parts someday.
posted 7 years ago
how do I execute commands in the command prompt. When I use the hgconvert and I am navigated to my folder of choice it says a bunch of different options like -s source type -d destination type, -r rev, -a authormap file..etc
I have attached a picture to show you what I am talking about. I am stuck on this screen. PLEASE help. Thanks I assume I am on the right path to converting.
Hopefully I am even in the right directory I assume db is database but there are a ton of files in the revs folder.
Jody Grisby wrote:Hopefully I am even in the right directory I assume db is database but there are a ton of files in the revs folder.
It looks like your db folder contains the SVN repository, but only you can know. (Note: I probably wouldn't put my working files onto desktop, but technically there's nothing wrong with it.)
How much do you know about version control in general? Have you ever worked with any version control system? Without any experience your task will be hard. With some experience you'll be able to understand Mercurial and SVN quicker, but I think you cannot do the task without understanding them.
In any case, Mercurial: The Definitive Guide looks like a very good book on Mercurial. I've learned most about Mercurial there. Version Control with Subversion looks equally promising, but I haven't read it. I'd say you need to read both of them so that you're easily able to perform basic operations on your own.
Learning Mercurial is really easy in my opinion. It installs easily on Windows, and there is no need to set up a server. Just create a new repository in Mercurial (hg init in an empty directory) and delete it after you've played with it (just remove everything from that directory).
The usual procedure for moving a project from one VCS (or repository) to another is as follows:
1. export the project to a local directory
2. import the project to the new VCS
Note that "export" is NOT the same as "checkout". When you check out a project, local housekeeping files are usually created to assist in checking changes back in. You don't want them. More to the point, they're going to be 100% useless and possibly even dangerous when importing into the new VCS. An export copies ONLY the project data without the metadata, and that's all you need or want.
The above process has one limitation. It assumes that you intent to discard all of the historical copies of the project and take only the selected version. If you want to actually migrate the entire history, you'd have to do a series of export/imports and probably some juggling of the different version copies in order to make the changes flow properly. Usually, it's easier to keep the old archive online for a while and use the new archive as an excuse to jettison the old deadwood.
"privilege" comes from the Latin words for "private" and "law" (legal) and dates to feudal times. To "claim privilege" meant that you were above the laws that applied to the common people.
Mercurial is capable of importing history from other systems, and it seems that Subversion is well supported in this regard (unlike the import from CVS, which has problems with tags and branches -- I worked around the issue by importing only the main branch and putting the important tags in manually).
However, not importing the history can be a solution. Of course, this process is much simpler and requires less expertise. This possibility was briefly mentioned, but I think it is good to articulate it as you did, Tim. It's up to you, Jody, to decide whether you need to import the history or not.
(There is also a possibility to import partial history, eg. every release of a project. I've once created a Mercurial repository this way, though it was not from another version control system, but from a set of backups. The process would generally involve exporting every version of the project that should be kept in the newly created repository and checking it in, and probably could be scripted. This can be still a valid option, especially if there are problems with importing the full history.)
See where your hand is? Not there. It's next to this tiny ad: