We use CruiseControl.NET to automate our builds and keep track of the Last Build Number. However, this number resets to one for newly created CC.NET projects. We would like the Last Build Number sequence to continue for branched projects (e.g., patches to existing releases).
Is there a way to globally increment the Last Build Label across multiple CruiseControl.NET projects?
Th build number is kept in the project's state file. If you branch, take the build number from the original project's state file and put it into the one of the branch project (or copy the state file and make the necessary edits like file name, project name etc.). Since the state files are XML this should be easy enough to do programmatically if your branch process is script-based.
Related
Normally a repository in Rational Team Concert compares itself to a base Stream to know what you have added or removed since you've started working.
a side-project started (before we started using RTC), and has now finished. It has the same folder/file structure as the structure within my local repository.
Is there some way to create a patch between this local folder/file and my current RTC repository so I don't need to manually compare the two file-by-file? I'm hoping RTC would automatically handle files where one or the other (but not both) have changed - but collisions would need to be viewed so I can make sure they are handled correctly.
If you have delivered all your change sets in your repo workspace, then you can import the files into the existing project. Then, when you check in those changes, you should be able to see any changes. One tip to avoid excessive changes, is to use the Eclipse or RAD source format (CTRL+SHIFT+F). Use that to standardize the original code first. Then import, and format the new code. Check in the code, and see if you have any changes. It should only show you changes that actually have real differences (not just whitespace).
I am about to make some major changes to my Mercurial repositories. As I am going to be using a Feature of Last Resort, I am looking for some advice and reassurance that I am not doing something stupid.
Where I Am:
I have a Mercurial repository with a complete history of all of these files:
/source
/secret_subsystem
/unclassified_subsystem
/common_files
Source is the Mercurial repository.
The secret subsystem folder contains code which is intellectual property we want to keep in-house.
The unclassified subsystem folder contains code which we want to outsource to a third-party to maintain.
The common files folder contains code that both subsystems depend on. We will be keeping ownership, but we want to share it with the third-party.
Obviously, I can't just push out my whole repository to the third-party company. The third-party would see too much.
Where I Want To Be:
Having read up on subrepositories, this is where I think I need to be:
Have THREE subrepositories: secret_subsystem, unclassified_subsystem, common_files.
Ensure there are no other files at the /source level, due to this recommendation.
Have the outsourcers create a brand new respository at the source level on their machines, and two corresponding subrepositories.
Push the unclassified_subsystem and common_files to the out-sourcer, pulling back unclassified_subsystem as required, pushing out new common_files repositories as required.
Maintaining History:
I would like to maintain the commit history, as much as practical, for all of the subsystems.
To do this, I will run the hg convert extension command three times, once for each subrepository. I will filter down to only the files that belong in each subrepository. I may also need to map filenames to move the files from ./common_files/foo.py to ./foo.py (for example).
My Questions:
1) Is dividing up a repository into subrepository a reasonable way of implementing security - viz. that a third-party can only see and edit some of our files?
2) Is using hg convert a reasonable way to create a subrepository from an existing repository, while still maintaining the history?
3) Will hg convert's filter strip out (a) all commits messages about files NOT in the filtered respository? Will it filter out all diffs for files NOT in the filtered repository?
There is another implied question: Am I heading into a world of hurt? If so, I will simply give up on retaining file histories, or even make them seperate repositories and forget about cross-repository commits.
I've not used subrepos so far, but I can answer 2) and 3):
2) Yes, sounds reasonable.
3) Yes.
There was a similar question just 2 days ago: Convert mercurial repository to subrepositories with full history (like hg log -f)
Because it seems like when
hg up default
or
hg up bugfix
is used in one Bash shell, then the other shell also changes to that branch automatically if an hg branch is used to show which branch it is. (so I think if it is a
Ruby on Rails server running, all of a sudden, the code will change to the other branch)
If using two separate clones, it can be done... as if there are two branches... but can be done using the branch feature of hg?
You have to use two separate clones.
Think about it. You're working on two different versions of a file. They differ in content. You have to change the file to reflect one of the two branches. How can a single file have two different contents at the same time (your two-shell idea)?
A different analogy: a shell is a window. The file is an object in the room. Even if you have two windows looking into the same room, you can't have the one object in the room be two different things at the same time. To do that, make an identical room next door, modify the object, and have the second window attached to the cloned room.
The different shells seem to be working on the same repository directory. This won't work since the directory is where the update happens and not the shell.
So you really need two repository directories i.e. clones in order to do this.
If these directories are on the same filesystem this won't cost much time or space since Mercurial optimizes this case by using hard links.
At least if you are on a operating system supporting hard links.
If by "shell" you mean two command shells open to the same directory, then yes, they both change because they are working with the same working directory.
One working directory can only ever be at one place in the repository history.
To work with two different branches or changesets in the project at the same time, make a second clone from the first, and then you can manipulate each independently.
I'm trying to sell our group on using Mercurial as a source repository rather than VSS. In the process of updating our build scripts, I'm running into an issue trying to retrieve files from the Hg repository.
Our builds are automated with NAnt and currently work for local builds or builds from VSS (ie, pull the source as needed from VSS). I'm trying to update them to work with Mercurial as well.
Basically, when I'm working with single files, I don't have any issues since I can just use NAnt's 'get' task (after getting the appropriate revision hash) to retrieve the individual file.
The problem that I'm having is when I need to work with a directory (and subdirectories) of files that aren't at the root of the repository. I can't seem to figure out the proper commands to retrieve/copy a subdirectory from the repository to my 'working' directory for the builds. I've spent basically the whole afternoon trying to figure out how to do this with the mercurial executables (so I can use a NAnt 'exec' task), and have basically hit a wall so I figured I'd try posting here.
Can someone confirm whether this is possible, and provide some suggestions as to how I might be able to do this? I realize that Mercurial tracks changes by files and not directories, but it seems odd to me that this isn't available out of the box (from what I can tell).
If it's just not possible, the only workarounds I see are either maintaining NAnt fileset lists of expected files to work with (ugh!), or cloning the entire repository to a temporary directory and then just copying the files from that source as needed (this feels like a cludge to me).
I realize that I could simply create another repository for the directory that I want to work with, but I'd prefer to not go that route since I think that would increase the complexity of what I'm trying to do by a significant amount (I would have to apply this a large number of times for all of the different libraries that we build..).
Mercurial doesn't let you get only part of a repository. You have to get the whole tree. It's much more whole-repo focused than svn is.
You could try and segment your repository into multiple repos and manage them using the subrepos feature. Then you can pull the subdirectories independently.
Often I want to have a main repository of source, shared by several "similar" projects. Each sub-project contains most of the same files, but is a specific configurable instance. That means there are usually a bunch of files and directories that need to be different for each instance.
In CVS I used to create the main repository and the secondary ones, then use the modules file to bind the two together for a specific name. In SVN I used svn:externals to tie back the secondary directories into the main one.
What works in Mercurial?
It depends on the nature of the specific files that need to be different.
If you can transform them as template files, then you can:
have a main repo shared as a SubRepo (as said in the documentation: SubRepos are the "closest to what you can achieve with Subversion directories marked with the svn:externals property")
have "similar" projects which will:
include that main repo as a subrepo (referencing a specific revision)
run a versioned script which will take those template files and build the actual files with the right values per environment.
That way you keep separate the templates (in the main repo) and the values (which each similar projects know about depending on their specific environment).
That being said, not every variation of files can be processed as "templates to be instantiated".