tags:

views:

281

answers:

1

I've used the 'hg convert' command to try to move my SVN repository to hg, and it seems to work (takes a while and prints out all the commit messages as it goes), but at the end the resulting Mercurial directory is empty. It has the .hg hidden subdirectory in it, and it's about 200 MB so SOMETHING happened, but none of the files are there.

Any thoughts?

The only thing I can think of as being involved is that instead of having top-level trunk, brankes, tags directories, we have many projects, each with their own trunk, branches, tags:


svn-repository/  
    Project1/  
        trunk/  
        branches/  
        tags/  
    Project2/  
        trunk/  
        branches/  
        tags/  

etc...

Could that be causing the problem? My understanding is that SVN doesn't really care how you organize the repository, but does Mercurial?

+12  A: 

You need to run hg update to get a working copy.

(Such mercurial repositories without a working copy can be used as pure communication points where revisions are pushed to or pulled from, much like a subversion server. In this case it was created by hg convert, but you can also create such repositories with hg clone --noupdate or hg update null. Omitting the working copy files saves some space.)

Also, I would recommend you convert each project separately. If you give the URL for "project1", hg convert will automatically detect the trunk, branches and tags subfolders and will do the right thing.

In mercurial, branches are first-class concepts rather than just folders who happen to have been svn-copied from the trunk. The branches don't live in any user-visible location like in svn. Having multiple projects (each with their own branches) in a single mercurial repository doesn't really make sense.

Wim Coenen
Ah of course, I can't believe I didn't try that. I'm still getting used to the difference between push/pull and commit/update.If I may ask a follow-up: why do you recommend breaking up the projects into different repositories? The reason they're grouped together now is because many of the projects are modular, and are used in different combinations together, but we still want to be able to branch them. Is this organization structure something that Mercurial will complain about?
Henry Jackson
@hvjackson: in subversion, you can merge changes between folders with a different path but a common ancestry. Mercurial works very differently: a merge is a revision which has two parent revisions. If you replicate the subversion way of doing things then you wont be able to merge properly. This may sound confusing - I recommend you work through the hg tutorial: http://mercurial.selenic.com/wiki/Tutorial
Wim Coenen
Or take a look at http://mercurial.selenic.com/wiki/Merge
Wim Coenen
@wocoenen: OK thanks for the help. Looks like I have some weekend reading to do!
Henry Jackson