Now, I have a source tree as following:
+ Dev
+-- Source
| +-- ...
+-- Samples
| +-- ...
+-- ...
Beginning, I had create a Mercurial repository in folder "Dev/Source". It's work fine. But now, I want extend the repository to include "Dev/Samples" folder too. I found only one way to do that. I must drop old repository and create a new in "Dev" folder. But the version history of original repository is so important for me. There has any solution to import original history to new repository? or Mercurial has another support to change the root folder of repository?
Thanks.
You can
use the convert extension to create a new repo with the aligned files (see the --filemap option)
create a Source folder in your repo and move all files within there
The first one provides a cleaner history, while the second one does not invalidate existing clones.
Related
I have file/directory structure:
main/.hg
main/subrepo/.hg
main/subrepo1/.hg
I have .hgignore file with such content
.hg
Finally, I want to make a commit in 'main' repository that will include all files in it, including all files from main/subrepo and main/subrepo1 and excluding folders main/subrepo/.hg and main/subrepo1/.hg (so all files from main folder, excluding .hg folders in it will be commited). But Mercurial skips main/subrepo/* and main/subrepo1/*. It does not include this subfolders/subrepos to commit fully. How can I fix this?
I'm going to guess that you have simply created some nested repositories, but not properly linked them as subrepositories.
Make sure that the root of the main repository has a file called .hgsub. You create the file, add the following and then add + commit the file to the main repository:
subrepo = https://path-to-subrepo/
subrepo1 = https://path-to-subrepo1
If the subrepos do not point to some remote server, you would use the local path of course.
I am trying to setup TeamCity build server. I am also using mercurial repositories.
My project structure is:
Main Folder
-Windows Form Application Repository
-Class library 1 Repository
-files subrepo 1
-files subrepo 2
-files subrepo 3
-Class library 2 Repository
I created a project in teamcity, added the 3 VCS to the project without specifying a checkout directory and the result was files from all 3 repositories in one checkout directory, resulting in build error.
I then went and changed the checkout directory of each VCS to C:\Projects. This resulted in a correct folder structure but no files in them (as if hg pull operation was done but not hg update).
Has anyone had any similar experience because I cannot find anyone complaining about such a scenario.
You can set checkout rules for each of your repositories. Checkout rule of the form
+:.=>subdir
will checkout all the content of your repository to the specified subdir (see
here for details).
As I understand your 'Class library 1 Repository' has 3 subrepositories. At the moment subrepositories are not supported with server-side checkout and checkout rules are not supported with agent-side checkout (here is an issue to vote/watch for).
As a workaround, you can create separate VCS root for each subrepository, but in this case TeamCity checkout the latest version of you repository, not the tracked commit from
.hgsubstate.
You should be able to do all of this using a single .hgsub in the root folder that will automatically bring in all of your other repos. You should have a single VCS root in TeamCity that pulls from the root.
I have a repository in which I have three subfolders.
A, B and a core folder.
I need the files of the core folder in A and in B. So every file of the core folder should be inside another folder in A and B and every update to the files should be commited to "core" and vice versa.
So I tried to make the core folder to a subrepository and add this to A and B.
So in folder B for example there is following line in the .hgsub www = ../core
In the main repository is in the .hgsub core = core
I assume there is something I do wrong, but maybe you have a hint how to achieve what I want :)
(Update)
To clarify:
The repository contains different "projects" for an app.
A is Android and B is iOS. The "core" contains HTML+JS files which are later used in the Android and iOS projects to build apps with phonegap.
If I understand you right, you have this:
repo
|
+-- core <--+
+-- A |
+-- core ---+ \A\core and \B\core should be equal to \core
+-- B |
+-- core ---+
There is nothing in Mercurial that will help you with this.
What you can do is this:
core-repo
+-- (content)
repo
+-- A
+-- core --- sub-repo pointing to core-repo
+-- B
+-- core --- sub-repo pointing to core-repo
This will allow you to commit changes to the sub-repo inside A, push, and then pull and update into the sub-repo inside B, keeping them in sync.
I am currently working on a project which is under mercurial control and I was looking to get a hook upon update to edit the .htaccess fille to avoid changing the APPLICATION_ENV to fit the "mode" the application should run/load configs/connect to the database.
My repository structure goes as follow :
Main dev repo (ENV : development)
+-- Stable repo (Production version) (ENV : production)
+-- Local dev repo (working version) (ENV : development)
+-- Prototype repo (prototyping repo) (ENV : prototype)
The part of the .htaccess I would like to have edited is the following (the first to lines of the file) :
# Application var
SetEnv APPLICATION_ENV development
I don't mind to run a python script ( or any other language) I am looking to the right hook to put in the .hg\hgrc file
That's not the right thing to do, since that would change the actual file. The next commit you make you would actually commit that change to your repository.
Instead, the recommended approach is to do the following:
Make a template file, and commit that to your repository, ie. .htaccess.template
Add the actual file, .htaccess to the .hgignore file to make Mercurial avoid it
Locally, make a copy from the template file to the actual file, and then edit that
This ensures that changes to the actual file, whatever they may be, will not be committed to your repository.
Some configuration systems also support conditional includes, so that you can something like if extra config file X exists, load X as well, and you would then do the following instead:
Commit the actual file to the repository, but make it bare-bones, containing default values
End the file with such an include-statement
Add the name of the file you're including to the .hgignore file so that you won't commit such a file to the repository
This would ensure that anyone can add to or override the default configuration by adding their own version of that file that will be included.
If I start out with a local mercurial repo, which I consider to be the "main" repo (pardon me my dvcs lords), and intend to use bitbucket as a backup and issue tracking facility, I can do all my changes in my local repo and do an "hg push" to send the changes back to bitbucket.
Don't I need to follow this "hg push" command run on my local machine with an "hg update"?
Why do you care what's in the working directory on BitBucket's servers? As long as you push the changes will be in the repository and visible on the BitBucket page.
EDIT: OK, I'm going to edit this to be a useful answer.
Say you clone down one of my repositories like django-hoptoad on BitBucket. You'll have a folder named django-hoptoad on your local machine and its content will look something like this:
django-hoptoad/
|
+-- .hg/
|
+-- ... my code and other folders
All the data about the repository itself is stored in the .hg/ folder. That's where Mercurial keeps the data about which files were changed in which changesets, and lots of other stuff.
You can think of it like this (though it's an oversimplification):
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
|
+-- ... my code and other folders as they appear in changeset 2
When you run hg pull and don't update, you pull any new changesets into the repository:
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
| +-- data about changeset 3 (NEW)
| +-- data about changeset 4 (NEW)
|
+-- ... my code and other folders as they appear in changeset 2
If you don't update, the ... my code and other folders will still be equivalent to whatever is in changeset 2, but the other changesets are still in the repository.
When you run hg update Mercurial will update the ... my code and other folders to the contents of the newest changeset.
django-hoptoad/
|
+-- .hg/
| |
| +-- data about changeset 1
| +-- data about changeset 2
| +-- data about changeset 3
| +-- data about changeset 4
|
+-- ... my code and other folders as they appear in changeset 4
Really, this means that what happens to be in ... my code and other folders doesn't have to match what's in the repository. You could just delete it and all the changesets would still be in the repository:
django-hoptoad/
|
+-- .hg/
|
+-- data about changeset 1
+-- data about changeset 2
+-- data about changeset 3
+-- data about changeset 4
If you committed right now, it would create a new changeset that basically says "no files". You don't have to commit though. People can still push and pull from you because the repository still has all the data about the changesets.
This is almost certainly what BitBucket is doing. You're never going to log in to BitBucket's servers, edit your code and commit there -- you're only ever going to push/pull/clone. That means the ... my code and other folders will never actually be used, so I'd imagine Jesper has it set up to delete it to save the disk space.
Since hg update only really affects the working directory, and the working directory on BitBucket is never used, you don't need to run hg update after you push to BitBucket.
I think you might be getting confused between the working copy (aka working directory) and the local repository. These are related but separate things. The local repository contains the full history of all tracked files whereas the working copy contains versions of the files from a particular revision plus your changes to them,
The hg command push and pull move changes between repositories and update and commit moves changes between your working copy and your local repository.
So if you push changes to a remote repository that will not change the local repository and so there's no need to run an update on the local repository. However, anyone using the remote repository will need to do an update so your changes are shown in their working copy. Conversely, if you pull changes from a remote repository you will need to do an update so that these changes are shown in your working copy.
Similarly, you need to commit all changes from your working copy into the local repository before they can be sent to another repository using push.
Bitbucket shows you the repository. As pointed out by Dave Webb, hg update is concerned with updating the working copy. When you do hg push you are transferring changesets in order to update the repository on Bitbucket -- and so the webinterface will show this.
There are no working copies on Bitbucket, as pointed out by Steve Losh. There is also no hg update being done behind your back.
You can experiment with this yourself by making a clone without a working copy:
% hg clone --noupdate repo repo-empty
then go into repo-empty and do hg log. You will see that even though there are no files there, the history (i.e., the repository) has still been cloned. You can make the files appear with the hg update command:
% hg update
and disappear again with
% hg update null
The working copy is only needed if you want to look at the files and make new commits. Otherwise you can remove it to save space. This is normally done in clones that are only used for serving with hg serve or the equivalent thing that Bitbucket uses.
No need to do a hg update on your local machine. Update is used when data is pushed TO your local repository, and you are pushing FROM your local repository.