1

I'm reading about subpaths in mercurial, and still can't understand the following: if subpaths file isn't versioned, how am I supposed to have at least a "primary" source for this? Should I version a subpaths file inside my repo along with .hgignore and such, and just copy it to the .hg folder where I do a clone?

Somebody still uses you MS-DOS
  • 13,029
  • 20
  • 64
  • 103

1 Answers1

4

I think that web page is really quite clear -- it certainly answers your specific questions when read carefully:

Q. if subpaths file isn't versioned, how am I supposed to have at least a "primary" source for this?

A. The entries in the subpaths file are propagated via the PushkeyConcept: the subpaths file is reproduced in clones of a repository and refreshed with every pull from the repository. The local subpaths file is completely overwritten with the entries obtained from the repository you pull from.

So you don't need to add it to the repository, but if both the client and the server have enabled the extension then the file will be created/overwritten on clone/push.

Q. Should I version a subpaths file inside my repo along with .hgignore and such, and just copy it to the .hg folder where I do a clone?

A. This is a new file that resides in the .hg directory of a repository. It is not version controlled.

So, no.

Community
  • 1
  • 1
Ry4an Brase
  • 78,112
  • 7
  • 148
  • 169
  • So, if I do a push from my local repository to a bitbucket account, is it going to magically add the subpaths file to it's (hidden) .hg folder - and if I want to "override" some of these files just use .hgrc in each cloned repository after? Isn't wrong being a file with important information not being versioned? – Somebody still uses you MS-DOS Apr 01 '11 at 02:30
  • 1
    Bitbucket almost certainly doesn't have that module installed, so this brand new feature won't work there. If you want the URLs tracked (and personally I agree with you and do) you put them directly in `.hgsub` as has worked since version 1.6. This new subpaths stuff is for people who don't want them tracked and is entirely optional. – Ry4an Brase Apr 01 '11 at 03:15
  • I have some git subrepos from github, and since the urls for projects can just disappear (or a fork becomes more useful than the original), I was thinking about separating the urls in another file, and started reading about subpaths. But I'm starting to think it would be the same thing having a separate file that changes urls and using the .hgsub, considering it's a single developer repository. – Somebody still uses you MS-DOS Apr 01 '11 at 04:23
  • 1
    Makes sense. Essentially, previously: you *had* to put the URLs in .hgsub and *had* to track them. Now with `subpaths` you can translate what is tracked using any `hgrc`, which without the extension probably means `.hg/hgrc` which is untracked. With the extension you get a middle ground where you don't track but can (with newer servers) clone/pull the translation information. The translations are additive, so you can put in a tracked URL, change it in the .hg/subpaths and then change it again in the .hg/hgrc give you tracked, pulled-but-not-tracked, and untracked layers as options. – Ry4an Brase Apr 01 '11 at 15:49