I'm not sure if this is possible, and if it's not any alternative solutions would be welcomed!
I have a number of solutions using Orchard - which mandates that any modules be in a certain directory inside it's folder structure. I have some modules, and based on the power of DVCS I'd like to be able to reproduce a new project using just suprepos. And also update Orchard with just Mercurial.
My folder structure looks like:
Project
- Orchard
- Modules
- Orchard module 1
- Orchard module 2
- My other code
I've just copied the orchard files to my repo, and then added my modules as subrepos.
What I'd like to be able to do is to also have the rest of the Orchard structure a subrepo. But I can't find a way to have a suprepo inside another subrepo. It won't be a nested subrepo, as the 'base' repo will be mine in both cases (orchard and the modules).
ie Project/.hgsub would look like:
Orchard = http://path/to/orchard
Orchard/Modules/Module1 = http://path/to/module1
Orchard/Modules/Module2 = http://path/to/module2
But this doesn't seem to work and I can't find documentation to say if/how I can do it.
Any help appreciated!
Edit: In case it wasn't clear I don't have write access to the Orchard repo, and I can't move the modules.
Just tested this scenario.
Here is what you need to do.
Add a folder to Orchard repository with 'modules' as folder (place atleast one file inside that). Do a commit with .hgsub (subrepos), now the subrepos should be added, do a pull on the subrepos and update their references in .hgsubstate.
Please share if you have any questions.
Related
I'm new to GitHub's template repositories. We've created a template repo for our course's code labs. Let's say it's on GitHub under myorg/labX. The students are using GitHub Classroom, which clones the template repo for each student under myorg/labX-studentlogin. We've got actions to run some tests against their code using GitHub's own CI, and I want to include badges in the repo's README.md to see the test results at a glance. So I know that
will include the badge, but this is the status of the template repo, not student repos. Is there a way to automate this so that when the students get their clone, it will contain a README with the URL that refers to the status of their own repo?
Turns out there is a simple solution, but only for GitHub's own Actions status badges. We've changed the image URL in our README.mds to relative.
The only minor thing is GitHub will insert /blob/<branch>/ into relative links when rendering the readmes.
For example, workflows/task1/badge.svg will become https://github.com/myorg/labX/blob/master/workflows/task1/badge.svg), which won't render. So we had to prepend '../../' to fool it.
TLDR: in repo's README.md, use
to get a badge for an Action status in this repo. This way, each student will get a badge referring to his own repo, not the template repo.
However, still looking for a way to use an external badge service like shields.io in a way relative to the repo.
I agree it would be a great feature to have.
It looks like at this point, GitHub Template Repositories do not support variable substitution, which is what would make it possible.
I see it is discussed briefly here:
Variable substitution for GitHub Template Repository Usage
Perhaps you should join the discussion and/or cast your Kudo.
Is it possible to create a subrepository using a sibling path?
Subversion is our "chosen" VCS here, but I've already had quite a few issues with out of date commits. It's much more convenient for me to dual version my files under Hg and SVN, and I have had great success with it. However, I've got a few other co-workers using Hg, and we've had no problems there except for one they probably haven't noticed.
Our SVN layout looks like this
Area/
trunk/
Program1/
Program2/
...
Services/
Program1ServiceA/
Program1ServiceB/
branches/
Program/
Program/
...
Services/
Program1ServiceA/
Program1ServiceB/
tags/
Program1/
Program2/
...
Services/
Program1ServiceA/
Program1ServiceB/
Which makes it kind of stupid when you're working on a project, because if your main project is comprised of Program1 and Program2, and a few more services... I can't get all of the changesets in one go, because we've got a repository that matches the directories. So I have to make sure 4 or 5 repos are in sync, especially with some service references.
I've had some good luck using subrepos beneath a single directory:
MainRepo/
Subrepo1/
Subrepo2/
But what I would like to do is specify a relative path so I can use sibling directories to the subrepository, so I could have something like this:
Area/
Project1/
Program1/ (points to ../trunk/Program1)
Program2/ (points to ../trunk/Program2)
Service1/ (... You get the idea)
Service2/
trunk/
Program1/
Program2/
Services/
Service1/
Service2/
But so far it hasn't worked like I expected it to. trunk/Program1 is an Hg repo, and my Project1/.hgsub file contains
Program1 = ../trunk/Program1
I've also tried ../../trunk/Program1
But the result of either of those is that a new directory is created: Area/Program1/Project1 that is empty.
So far, the only search results I've been able to find use http based repositories for subrepos, so I'm not sure where to go from here. Our dev env is Windows 7, so the "easy" answer is to create junctions, but my primary concern is to make things like this easy to do, so the barrier to entry is as low as possible, and even something as easy as mklink /J Program1 ..\trunk\Program1 from an administrator cmd window is one more thing that would prevent people from migrating to a better workflow.
Is it possible to add a subrepository like I want, or is there a better way to do what we're doing?
Subrepositories are always inside another repository. In other words, subrepositories lets you version a collection of repositories where some repositories are nested inside other repositories. Subrepositories can thus not be siblings without creating an outer repository.
The relative paths you're talking about are used when Mercurial needs to figure out where to get a new subrepository from. That is, when you run hg update (or when it's run for you as part of hg clone) and Mercurial notices a .hgsub file, then it needs to create the subrepositories mentioned there. To create the subrepo, Mercurial uses the path on right-hand side:
sub-A = relative/path
sub-B = C:/absolute/path
Here sub-A will be checked out in the root of your working copy using the command
hg clone <default path for main repo>/relative/path sub-A
and sub-B is checked out using the command
hg clone C:/absolute/path sub-B
That's all — it's a very simple mechanism. I've tried to describe this in my subrepository guide and it's also explained in the wiki.
For your case, you can make a thin shell repository for the parts that belong together. This repo will be like Project1 above and have Program1, Program2, Service1, etc as subrepos. The .hgsub will look like this:
Program1 = Program1
Program2 = Program2
Service1 = Service1
Service2 = Service2
By using "trivial subrepo paths" you make things easy: a clone looks just like the clone source and everything is kept together.
A final note: unless you use Program1 or Service1 in other projects, then you should just put everything into a single repository.
I am in the process of rebuilding a API documentation site for an open source project where we want to keep an archive of previous releases. I am wondering how I can configure Jekyll to generate the right hierarchy?
We have the following directory layout in our current /docs folder (which we would like to reuse in Jekyll somehow):
current/
v1/
v2/
v3/
Whenever we release a new version the current folder gets copied to a new folder (say v4). The contents of each folder is something like this:
introduction.md
testing.md
api-foo.md
api-bar.md
I'd like these to be available under the url domain.com/v3/testing/, domain.com/current/testing/, etc. I see that I could probably employ collections to do this, having one collection per version. To do this I see myself auto-updating the _config.yml as part of a build script (I made an example doing this here), but I am not sure how to progress from here, or if using collections for this is the wrong approach ...
This is too brief of an update to be of real quality, but thought I would mention that we solved this in the end in the Sinon project. Check out the repo at GitHub sinonjs/sinon and see the docs folder as well as the scripts called from package.json.
Feel free to improve on this answer by editing it and adding content and links.
I'm comming from SVN background and I'm having a problem of adding to my main repo a subfolder of subrepo. That means that I don't want to add the whole subrepo to my main project - only a part of it. In my situation I want to include only source files of my library excluding all unit tests.
I have created .hgsub file and wrote there:
libs/my_std_lib = https://myreposhost.com/my_std_lib_repo/src/main/java/
But when I'm trying to synchronize libs/my_std_lib folder I get such error: HTTP Error: 404 (Not Found)
When I try to synchronize without subpath (https://myreposhost.com/my_std_lib_repo/) - it works well.
So what do I do wrong or this is not posible in hg?
The answer is pretty simple : it's impossible to clone only a part of a repository with Mercurial.
By extension, you can't add only a part of a repository as a subrepo.
Sorry.
I'll try to explain my situation as concise as possible:
I have a template project that I use as a template (duh) when starting a new project.
This template project evolves, and sometimes I update it as I am working on another project.
So imagine that:
Template project: template.file
Project A: template.file & projectA.file
Project B: template.file & projectB.file
(all projects are under revision control) Now when I change template.file in project A, I would like all other template.files in all other projects to update
I am on windows, using tortoisehg and I am relatively new at this versioning game. I suppose I would do this with branches? But then wouldn't the projectA.file and ProjectB.file also get added to the template project?
Here is something you could do:
Go into the template project and merge in project A, then prune everything you didn't want before committing. This is rather laborious and time consuming.
Then you can go into project be and pull from the template project and very carefully merge.
I would not do this for any number of reasons. First, it's messy and error prone. Secondly it results in both projects containing all the files of all the other projects, even if in the tip revisions those files are considered deleted. The history is still all there.
Here is another thing you could do:
Use hg export to export the change that modifies the template file from project A. Then use hg import to import that change into your template project.
Then pull from the template project into both project A and project B and merge.
This requires that you discipline yourself when modifying project A and always make modifications to template files their own change.
Alternatively, you can hand modify the exported change to remove extraneous changes.
Here is a third thing you could do:
Always modify template files only in the template project. Then you can pull from the template project into projects A and B and merge.
There's nothing in Mercurial that will you out of the box with this, cleanly.
You could:
Stuff everything inside one big repository, just separate them into different directories
Use sub-repositories, meaning that Project A and Project B would reference the template project as a sub-repository
Just make a copy of the file in question to all the other projects/repositories
In either of these 3, there's nothing that will help you make sure a file inside each repository is in sync.
In the first case, you would have 3 distinct copies of the template.file, and updating one will not update the other two, and there's nothing in Mercurial that will help you with that.
In the third case, the three repositories are completely distinct and separate, which means changes in one does not propagate into the other.
The second case, however, can be done, but if you need to have a copy of the file inside the Project A/B repositories, you're back to the third case.
However, you can make the template project a sub-repository of Project A, and instead of making a copy of the file, out of the template project and into Project A, you refer to the one you have in the sub-repository.
This is the way Mercurial handles such things.