I originally posted this question and found that Bitbucket does not support nested sub repos (CORRECTION: Bitbucket was not the problem at all...potentially bad information or misunderstood what they meant by nested subrepo) . I had to arrange them in Tortoise as sibling Repos. Mercurial to Bitbucket - Subrepository - Repository is unrelated error
My problem now is that TortoiseHg/Mercurial does not pick up the changes in my subrepos.
My directory structure looks like this: (sibling and not child folders)
MainRepo (to hold all subrepos)
SubRepo1 (main project)
SubRepo2 (class library)
SubRepo3 (class library)
etc...
In my .hgsub file, i have the following
SubRepo1 = ../SubRepo1
SubRepo2 = ../SubRepo2
SubRepo3 = ../SubRepo3
etc...
My problem is that the MainRepo does not detect any of the changes in my SubRepo. I noticed that there is now a folder for in the MainRepo folder for each of my subrepos. I suspect TortoiseHg is looking in there for changes...and not my ../SubRepoX folder.
Can anyone guide me to a working SubRepository scenario for TortoiseHg pushing to Bitbucket
UPDATE: See this link for the resolution to my subrepo problem. Recommended way to coordinate versions of multiple dependent mercurial repositories?
The subrepo directory reference should be relative to the location of the .hgsub file.
Therefore, you should have = ./SubRepo rather than ../SubRepo.
Here's the official docs. They're not too hard to read.
Related
I have a shell repository OriginalWithSubrepo with a subrepository Sub containing a bunch of actual files.
When I clone OriginalWithSubrepo like this
hg clone --pull --noupdate "C:\TestRepo\OriginalWithSubrepo" "C:\TestRepo\OriginalWithSubrepo-clone"
The clone thus created contains just a few mercurial housekeeping files, there is no actual data from the original Sub\.hg directory. I don't know what those files mean but apparently they are enough to recreate the repo because when I update the working directory in clone, the whole thing gets filled out with all the files, including inside the Sub\.hg directory. However, if I clone, then rename the original, and then attempt to update the clone, it doesn't work saying the OriginalWithSubrepo is not found, which means it's all based on links to the original.
This problem doesn't arise when I run clone with update, or when I clone a repository without subrepos.
It behaves the same when I clone to a network share, which is where I really want it to work.
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
Windows XP, hg version 3.4.1
When you add the first subrepo to the parent repo, .hgsub is added to the parent repo. The subrepo only becomes a subrepo from the changeset that commits .hgsub.
When you do hg clone --noupdate --pull parent parent-clone, parent-clone is not at any changeset yet, and so not yet at a changeset at which the subrepo has been created
So how do I make a fully independent clone of a repo with subrepos (w/o a simultaneous update)?
I don't think you can do this as such.
But this may achieve what you're trying to do (I'm reading between the lines here, but I'm guessing to have the repo on the share, but without any files visible):
Create repos on your network share for your parent and sub \\fileserver\repos\OriginalWithSub\ and \\fileserver\repos\Sub\
Modify your local OriginalWithSub .hgsub set the remote path to be \\fileserver\repos\Sub\ and commit.
push your local repositories to their respective network share equivalents.
Both repositories now exist on the network share, without any files visible apart from inside .hg, and you can clone \\fileserver\repos\OriginalWithSub\ (with update) from another computer and get the full history of both OriginalWithSub and Sub.
I have a repository with a number of sub repos, and I wish to clone all of them without having working files. When ever I try to clone using --noupdate no of the sub repositories are available in the closed repository. Is this due to the lack of a .hgsub file in the cloned repository?
That is sort of the reason why.
More specifically, subrepos are implemented not as their own repos, but as part of the working copy their parent repos ( conceptually, you can think of a subrepo as being just a single file existing in your main repo ). However as soon as you update, the repo and subrepos will be at the same state as if you had cloned without using -noupdate.
Here are the steps I've taken to build the repo and subrepos.
Everything is hosted on Bitbucket.
Per best practices, created a skeleton repo to hold all of the subrepos. Cloned to my machine.
Cloned primary project as subrepo1 (within the mainrepo directory structure).
Added primary project to mainrepo as a subrepo1.
Committal of mainrepo works as expected.
Pushed successfully mainrepo and subrepo1 to Bitbucket.
Proceeded to clone another subrepo2 to mainrepo directory.
Added subrepo2 to mainrepo as subrepo2
Committal of mainrepo works as expected.
Push of mainrepo results in "Repository is unrrelated" error after is "searching for changes" Error occurs only on the newly added subrepo2.
Here is directory structure:
mainrepo
--subrepo1 (main project)
--subrepo2 (class library)
I've spent countless hours trying to get this working and I must be missing something obvious.
What is causing this error and what am I missing?
I need to be able to add additional subrepos as the project grows.
The steps that I took to make my example are as follows:
Create MainRepo on BitBucket
Create SubRepo on BitBucket
Clone MainRepo
Clone SubRepo as a sub-directory of MainRepo
Manually create the .hgsub file with the contents SubRepo = ../SubRepo
Add the .hgsub file to MainRepo, commit and push
Create SubRepo2 on BitBucket
Clone SubRepo2 as a sub-directory of MainRepo
Manually edit .hgsub and add SubRepo2 = ../SubRepo2
Commit and push MainRepo again
From then on, I could edit either of the two sub-repositories and see that they had changed when looking at MainRepo in the workbench. I could then commit the changes to the sub-repositories, commit the sub-repository states in MainRepo and push all three repositories with a single push from MainRepo
The way that you said that it was set up by TortoiseHg in your other question (subrepo = subrepo) won't work with BitBucket because of how their structure is. I think that you can only have repositories at the top level like this:
bitbucket.org/SteveKaye/MainRepo
bitbucket.org/SteveKaye/SubRepo
whereas having the line subrepo = subrepo is trying to set up a structure like this:
bitbucket.org/SteveKaye/MainRepo
bitbucket.org/SteveKaye/MainRepo/SubRepo
When you push this it looks like it is trying to push SubRepo into MainRepo which would explain the unrelated repository error message that you are getting.
The .hgsub syntax is such that the left of the equals defines the folder in the working copy where the repository will be and the right of the equals defines where to get it from. When the right of the equals is a relative path, it defines where the sub-repository is on the central server relative to the main repository. So in the example above, you go up one folder to bitbucket.org/SteveKaye and the SubRepo is contained in that folder.
The documentation says:
The source path of a Mercurial repository can either be a relative or absolute path or URL. It is generally recommended to use trivial relative paths where the source path is the same as the working dir path: This will ensure that the subrepositories always can be found 'in place'.
Other relative paths can be used if the subrepositories can't be hosted 'in place', for example because of limitations of a central repository or hosting service. A consequence of using such non-trivial relative paths is that clones can't be cloned.
This looks relevant to your situation when using BitBucket and I'd expect that your clones can't be cloned as it says in the last sentence.
Summarised Question:
Are github-hosted sub repositories within a mercurial/kiln repository possible, and if so are they automatically updated/cloned when the parent mercurial repository is operated on by a hg clone or hg commit command?
Detailed Question:
Following on from my question that was answered so excellently here , some of my third party code is in folders I downloaded a while ago from opensource efforts on github. Since at that stage I was not using version control, those folders where just standard folders that now been incorporated as sub repositories in mercurial.
This is obviously not ideal, as for one thing, new versions of the libraries may have bug fixes, or new features I wish to use in the future. I also may need to locally customise some of the libraries.
I can see from reading this link that it possible to have mercurial "know" about those git server urls (and revisions), so I can then have mercurial clone the github hosted libraries direct from their parent repos.
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
What is also not clear is, if I were to do this, and it transpired that code might need to be customized from within that github-cloned repository, would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
Am I right in saying that when I clone the parent (mercurial) repos, those files will be pulled from github, without having to separately manage this using git?
Yes, clone of a Mercurial repository that contain subrepositories will trigger a clone of the subrepos too. It really happens on update. Mercurial notices the .hgsub file and issues the needed hg clone and git clone commands for you. It uses the information in .hgsubstate to know exactly what revision to checkout.
The subrepositories can be hosted anywhere. For a Git subrepository declared like
foo = [git]https://github.com/user/repo.git
Mercurial will simply issue the corresponding clone command:
git clone https://github.com/user/repo.git foo
It's then your reponsibility to later go into the foo repo and use Git to fetch new commits as necessary. After you fetch/pull new commits, you can make a top-level commit to record the new state of the subrepo in the .hgsubstate file. Use hg summary to see if a subrepo is dirty in this sense.
[...] would I need to use git to manage revisions of the local files, or would mercurial do that by proxy? eg id I were to hg commit -S would mercurial invoke git on my behalf to handle that?
When you edit files and make a top-level hg commit, Mercurial will make sure to commit the subrepo first (if you use hg commit -S or if ui.commitsubrepos=True). If you make a top-level push, then Mercurial will always push the subrepos first so that you always have a consistent set of changes on your server.
I am in the process of setting up some third-party subrepositories under a Mercurial repository. One subrepo is another Mercurial repo hosted on Bitbucket.
Since it is a public repo, and I am not a contributor to it, I don't wish to push back to it. However I would like to still have the repository automatically cloned when I clone the parent repository. For one thing, I'd like to have access to the collective history of the subrepository so I can see what may or may not have changed over time.
So, I made an entry in the parent repo's .hgsub file as follows:
thesubrepo = https://bitbucket.org/user/repo
and cloned the repo using
$ hg clone https://bitbucket.org/user/repo thesubrepo
I made a commit to record the subrepo state. I then went to push my parent repo back to it's server (Kiln) only to discover that it was trying to push the subrepo I back to the Bitbucket server. The push to the Bitbucket subrepository appears to not do anything, though.
I did not observe this behaviour when I made a Git subrepo in the same manner (hosted on Git hub) using an entry in .hgsub like this
abc = [git]git://github.com/xyz/abc
Is it best for me just to do this by not setting up a subrepository, and just let Mercurial store the files as files? Or (preferably) is there some setting somewhere that I can use to tell Mercurial to never actually push the contents of this subrepo back to it's source location?
I'd rather be able to configure it to only push those subrepos manually, so if anyone can shed some light on this, I would appreciate it.
I found a reference to commitsubrepos = no in another stack overflow answer, which as far as i can tell is about commits, and not pushes of sub repositories. I then looked this up on the mercurial website, in the hope there might be some reference to a setting pertaining to pushing subrepos, but... no
You cannot (currently, as of version 2.0) ask Mercurial to not push subrepositories.
The fundamental problem is that Mercurial must ensure that you have a consistent state on the remote repository when you push. It would be unsafe if you could push back to Kiln and then have a changeset there that references a revision on Bitbucket that isn't there. Mercurial doesn't know if a changeset you have locally is published or if you created it — so it has to (try to) push.
We're currently working on a concept called phases. With that in place, Mercurial will begin tracking if a changeset is created locally or already published. That can be used for subrepositories too: if there are only changesets in the "public" phase in a subrepo, then there's no need to try pushing!