I would like to get all the files checked-in a private branch and only the those files checked in.
What config spec would you recommend?
Let's say prvt is the private branch:
element * .../prvt/LATEST
Would that work?
What if I want to load only those elements which are branched out only in prvt branch not any other element as I suppose
element /myVob/myPath /main/LATEST
element /myVob /main/LATEST
might get files which branch out from the main latest also in myPath directory.
But this is very much useful only for directories as I wouldn't have branched out the directories of the checked in file element in the private branch
This will only work if every element has a prvt branch.
So if your files are in /myVob/myPath, the config spec
element * .../prvt/LATEST
will select the right versions (those in LATEST of prvt branch), only if /myVob has a prvt branch (i.e. has already been checked out / checked in in that branch), and if myPath has a prvt branch.
If the leading path has no prvt branch, no version will be selected, meaning the files within that path won't have a chance to be selected by your selection rule.
That is the real issue here.
That is why I recommend adding some stopping rules:
element * .../prvt/LATEST
element /myVob/myPath /main/LATEST
element /myVob /main/LATEST
That way, within /myVob/myPath, only the right versions are shown, but for the path *leading** to those files, you have at least backup config spec rules which allows you to at least select one version.
If you know the branch from which prvt branch has been done, using that branch name would be safer.
If you don't '/main/LATEST' is a sure bet, since the main branch always exists.
the best way I found out to do this task was:
cleartool find . -version "brtype(BRANCH_NAME) && version(\main\VIEW_NAME\BRANCH_NAME\1)" -print
Yes, I know, \1 in the end will only return the first version, but that's ok, by doing this, you already know every single file you have checked-in, at least once.
Related
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 need in my source code to have a text file which contains the current Tag and Branch name.
Generally I want it for browsers "cache killer", I can read this file and append it to every script/css call.
for example: <script src='file.js?v=1.0'></script> the 1.0 will be coming from this generated config file.
I am working in PHP and C# So I need this kind of functionality built in the source control.
Is it possible? I dont want to do it manually, to risky.
Thanks
hg log -r. --template='{branch}-{latesttag}' would give you the branchname of the currently checked-out revision and the last tag preceeding it in its list of ancestors. Either use that call to hg directly or write it to a config file.
See hg help templates and maybe also hg help revsets
I would like to keep two versions of a static html file in my git repository. Both are basically identical, except for links for scripts, media etc (dev version vs. live version).
Right now I keep the dev version in repo, and overwrite the live version values manually on the live machine (=I have local git changes there). I am not happy with this setup, because there's manual labour for each push/pull.
What is the best flow for managing files that cannot be split into config/rest sections (like HTML)?
You could...
Remove the file from your repository and just manually populate it. If it doesn't change very often, this works just fine.
Remove the file from your repository, and generate it from a template via a post-merge script in .git/hooks/post-merge (this hook is run, for example, after git pull).
Name the file after the branch or hostname or some other variable (e.g., static.master.html vs. static.develop.html, etc) and dynamically determine which one to use at runtime.
Those are some ideas. I imagine other folks will contribute additional suggestions.
Expanding on the 2nd bullet point by larsks:
You could keep two copies in the repo (say it were your homepage) index.dev.html and index.prod.html. On the remote, your post-merge script could do something like:
cp -a index.prod.html index.html
or
truncate -s 0 index.html
cat index.prod.html >> index.html
Another problem beside renaming is to keep the content of the both files in sync. So having dedicated files for the same reason only differing in one minor path is a lot of redundncy, if you change one, you have to think on updating the other as well.
OK, you stated that the HTML file is static, but here a line of PHP to generate the difference would solve our problem
Achim
We use tortoise hg with Kiln. In my vs 2010 c# project there are some files that are part of the repository but I would like tortoise hg to ignore them when I make a commit.
For eg., say in a login screen I may hard code the userid, password for testing. I dont really want this file considered during a commit. I understand .hgignore file but this really works for files that are not part of the repo. Any trick in tortoise hg to ignore files that are part of the repo ? (so they do not show up as modified (M) during a commit.) thanks
I always use a combination of .hgignore and BeforeBuild (in the .csproj file) for things like this.
In one of my pet projects, I have the following setup:
App.config contains my real hardcoded user id and password for testing.
App.config.example is identical, but with fake data like "dummy_user" and "dummy_pw".
App.config is not part of the repository, and it's ignored (in .hgignore).
App.config.example is part of the repository.
Then, I have the following in the BeforeBuild target in the .csproj file of my solution:
<Target Name="BeforeBuild">
<Copy
Condition="!Exists('App.config')"
SourceFiles="App.config.example"
DestinationFiles="App.config"/>
</Target>
All this together has the following effect:
the config file with the real data can never be accidentally committed to the repository, because it's ignored
the repository only contains the config file with the example data
if someone else clones the repository to his machine, he won't have the "real" config file...but if it's missing, it will be automatically created before the first build by Visual Studio / MSBuild by simply copying the .example file (and then he can just put his real login data into the newly created App.config file).
if an App.config with real hardcoded user data already exists, it won't be overwritten when building because the BeforeBuild event will only happen if App.config does not already exist
The answer by Christian is the right one, but I want to mention that TortoiseHg supports what you want with their Auto Exclude List.
One problem with an exclude list is that it cannot work with merges: you must commit all files when you merge and so you'll have to do a little dance with shelve, merge, commit, and unshelve.
When you do a TortoiseHG commit, there is a list of files with checkboxes by them. Deselect the files you do not want comitted.
Or, on the command line, do a commit of the form hg commit --exclude "pattern", where pattern is defined in the hg man page.
You could always use hg forget.
When I create a new repository, I can ask TortoiseHG to give me a .hgignore file. Is there a way that I can customise what that file will look like, rather than having to go and get one manually from somewhere every time?
It's an old question, put still popped up as the first result on google, so here is an update:
In the TortoiseHg settings under the tab TortoiseHg users can specify the path of a Repo Skeleton. You can put your predefined .hgignore there, and it will be automatically copied during hg init.
See also:
#3569 Allow user-defined default .hgignore file when creating a new repository
TortoiseHG Docs
Like Tim already said in his comment, apparently it's not possible to do this.
Take a look at the following issue from TortoiseHG's bug tracker:
#966 Include some reasonable defaults in .hgignore on repo creation
Quotes from this link, both by Steve Borho (THG project lead):
This topic comes up on the Mercurial mailing list once a year or so and Matt always shoots it down. There is already support for user level ignore files; one could add these globs to a global file and be done with it.
and:
If a user has files or directories that they always want to ignore, they can add those to a global ignore file without having to introduce any new behaviors in THG.
So putting the things you always want ignored in a user-global ignore file seems to be the only option (even though it's not exactly what you're asking for):
Would like to create some defaults for my .hgignore files in TortoiseHG/Mercurial
(the question that I posted in my comment above)
Global hgignore usage