1

I have an SVN repository which contains a number of loosely-related subfolders in its trunk.
I would like to convert it into HG repository, turning each of these subfolders into a separate HG subrepo.
At the same time, I would like to access combined change log of all subrepos in the top level repo.

So I created an empty HG repo, some empty subrepos, linked their names and locations by .hgsub , checked that I can clone this repo together wth its subrepos to another comp ...

Then I tried to make partial SVN clones to subrepos (specifying SVN URL with .../trunk/subfolder for each subrepo). But they did not show in top-level HG history for a reason unknown to me.

I started from scratch, and tried to put SVN trunk URL into top-level .hg/hgrc and to do 'hg pull'. But it pulled the whole SVN repo into top level, and subrepos were left empty.

And now I would ask you what do to next ?
Probably I am missing something since I am new to HG. I would appreciate any your advise.

muwlgr
  • 23
  • 4
  • are you performing an SVN->Hg conversion as a one time thing? Or are you trying to move back and forth between the two? – dls Apr 22 '11 at 17:39
  • We will need two-way replication for some initial period. Then freeze SVN repo and modify only HG one. – muwlgr Apr 23 '11 at 04:56

1 Answers1

2

Reporting revision history and individual file statuses get a little bit complex when it comes to Hg subrepos.

Revision history

The revision history of a subrepo is not visible from the parent repository. This makes sense when you think about it because each subrepo is literally a different repository - there is really no good way to overlay two separate histories, nor would that information be very useful. From the command line you would have to navigate into each subrepo directory and execute a hg log to see the history. From TortoiseHg 2.X.X, from the commit view, you can double click on anything marked with an S to open up that subrepo in the TortoiseHg GUI.

Local modifications

Local modifications to subrepos can be seen from the parent repo, but not necessarily in the same way for each command. For example, if I have a repository that looks like this (where sub is a subrepo):

/project
  |
  ----> foo.c
  |
  ----> sub/
         |
         ----> bar.c
         |
         ----> more.c

If I modify both bar.c and foo.c and then perform an hg status from the command line I will see the following:

> hg status
M    foo.c

But if I add the subrepo argument -S I would see:

> hg status -S
M    foo.c
M    sub/bar.c

If I am using TortoiseHg v2.X.X it will mark foo.c as modified and it will mark sub as modified, but I would have to double click the subrepo to view the actual file modifications.

Conversion notes:

In terms of performing the conversion itself - check out the convert repository extension. If you are performing a one time conversion and then abandoning the SVN repository this would probably be all you need. If you're going to try and work back and forth between SVN and HG you will probably have a few more issues.

Something I've done successfully in the past is overlay a Hg repository on top of an existing repository. I'm not sure if this would work well for SVN and Hg, however.

dls
  • 4,146
  • 2
  • 24
  • 26
  • So, you're saying there is no possibility, for example in tortoiseHG, to rightclick on the top-level repo and see all the changes of all subrepos? – Vasyl Boroviak Apr 22 '11 at 19:11
  • Thanks. Currently I'm using TortoiseHG over SVN repo (gsubversion extension). Now we are trying to migrate to HG. We are hesitating if we should split our 2GB HG repo onto 7 subrepos, or not. So, that is why all the questions arise. – Vasyl Boroviak Apr 22 '11 at 19:59
  • 1
    @Vasiliy Yes, this is an important decision. If you're going to try and re-use portions of that 2GB repo, I would recommend them. I would also recommend v2.X.X of TortoiseHg - it seems to have better subrepo support. Good luck! – dls Apr 22 '11 at 20:04
  • You were right. TortoiseHG handles subrepos quite gentle. The UI design is friendly as much as it was possible to make. But HG subrepos still does not support some very important (for me) operation in one click - the mq strip command. Thus subrepos still not very useful HG feature. Too pity we have to give up subrepos. – Vasyl Boroviak Apr 23 '11 at 19:52
  • @Vasiliy You are correct, mq stipping a changeset from the parent will not strip the referenced changeset in the subrepo. If you think about it, when one subrepo is being used on different projects, it doesn't make sense to strip out a subrepo changeset just because one consuming project doesn't want to use it anymore. If this is something you think you need, you might want to consider consolidating your subrepo and repo into one repo. – dls Apr 23 '11 at 22:28