Often when I'm delivering activities for a build, I get an issue where one or two activities have dependencies on other activities that are not yet ready to be deployed.
What I want to do in most of these situations is force a merge between the two changes and deploy the stream, so that any changes in development that are lost during merge can be recovered.
What happens instead is that ClearCase forces me to move these changes to a new activity and include the activity if I want to make the delivery at all.
I have heard that I can render a branch obsolete - which would be satisfactory in some cases, but occasionally there are changes I might want to include in the deployment - is there any way for me to force a merge between two changes before making a deployment?
Sometimes, UCM doesn't let you make a deliver because of "linked" activities, that is because a previous deliver has created a timeline which made those activities linked (meaning you can no long er deliver one without the other)
In those instances, you still can merge any activity you want in a non-UCM fashion with cleartool findmerge: see "How to merge changes from a specific UCM activity from one ClearCase stream to another" for a complete example.
Then later, you will make your deliver (with all activities from the source stream).
Adding on to #VonC's answer...
There are a couple of ways that you can wind up with activities linked together:
Version dependency: Activity A has versions 1,2,&3 of foo.c Activity B has version 4 of foo.c. You can sometimes also have "1 & 3" and "2 & 4"
Baseline Dependency: Activities A and B were delivered in the same deliver operation from Stream X to sibling stream Y. From that time forward, A&B have to be delivered together since they are in the same "deliverbl" baseline.
Number 1 can be changed by rearranging the changesets using
cleartool chacct -fcsets {Activity X} -tcsets {activity Z} foo.c
Number 2 is pretty much set in stone...
Related
This is a programming language and version control system agnostic question.
There is a source code tree and two patches X and Y. Each of them apply cleanly to the source code tree. But applying one of them (either X or Y first), then another one, results in second patch failing to apply (patches conflict).
Is my only option applying one of them (probably the biggest one, so most of work gets done automatically), then merging the other one by hand and resolving conflicts, or there are better tools/practices to handle this scenario?
The goal is to avoid this situation from happening as there's no easy solution to merge.
In order to avoid, make small commits with their tests and push them to the source repository. Other guys in the team will be forced to pull the latest changes in order to commit their code, and this will ensure that nothing gets broken.
I encourage you to avoid having multiple teams manipulating the same part of the source code. Create a good structure and if possible break down the project into smaller projects.
In serena dimensions, there are two parallel streams (Stream A and Stream B) from the same ancestor. I require to merge few modified files from Stream A to Stream B. Can someone guide as how this can be done.
None tool provides "automatic merging".
Suppose you have stream A and stream B, same item in different revisions: X 1.0 - production, X 1.1 - Stream A, X 1.2 stream B
First you must choose wich stream will get the "final merged" revision. You can use a third stream, just for all merges, regression tests and action to production.
Usualy you create a "third" version, (ex: X 1.3 if you choose merge based on production), or use a existent stream revision (ex: X.1.1.1, if you chose merge on existent revision 1.1 on stream A).
Use "compare" tool to check differences and proceed merging.
It can also be done locally, by having both streams updated each in its own folder (I assume you have them both as this). Locally merge your changes from Origin to Destination stream (can be all or just the selected files). Make sure that nothing was broken on the Destination stream and make a deliver or check in of the Destination stream.
A good practices is to have all items written, completed or baselined in your Origin stream, whichever makes more sense in your project, prior the merging of the streams, and then as a double check you can Get your Destination stream from the server into a different path and verify that all the changes are merged and nothing was broken. Also action the items as written, completed or baselined in the Destination stream once this final check was successful.
My project uses hgext.notify. Currently incoming.notify = separate messages on every changeset. Considering changegroup notify, but even that contains info about every changeset, just all in one big email.
Here's the problem:
My work style is "check in early and often". I make many small checkins, usually on branches. Task branches. Eventually integrated.
My teammates do not like seeing messages for all of my checkins on my task branches.
We are considering using a history editing extension like collapse or histedit to reduce the verbosity - but I dislike losing history. I just want not to bother them with every individual changeset.
Q: is there a way, some configuration for an existing hook, or some alternate hg extension, that can be set up to do notifies as folllws;
a single message per changegroup (that's okay)
a single user provided message per changegroup - not just concatenation of all the branch changeset messages
filter out only the changest messages for, say, the trunk (the default branch in hg parlance). I.e. leave the branch changeset messages in, but don't send email.
(Note: my pushes typically involve several changesets on a branch, and then a merge onto default. So it is not enough to just filter the entire changegroup in or out according to what branches are affected.)
diffstats not between the tip and every changest on the branch, but just between "important" changesets on the trunk (default branch) - which may be evety changest on the trunk.
I'm afraid no such extension exists. The notify extension is just a basic way to send off emails with a little room for customization.
It sounds like you have a particular idea about what you want. I suggest you see if you can formulate it as a revision set and then simply use hg log in a changegroup hook. Pipe the output to mail and you've got yourself a very simple notify extension that you can customize to your hearts content!
What I'm saying is that the notify extension is not that complex and in many cases it can be replaced by a suitable invocation of hg log. You can even use a custom template for hg log if you want to change the output more than what hg log -v or hg log --patch does.
The tricky part (and the part that's not entirely clear from your question) is to filter out exactly the right changesets. You mention "important" changesets in point 4 above, but I'm not entirely sure what makes a changeset "important". If it is important when it's a merge from a feature branch into default, then something like this might be a start:
hg log -r "$HG_NODE:tip and children(not branch(default)) and branch(default)"
By taking the child changesets of the non-default changesets and intersecting with changesets on the default, we get exactly the merge points where feature branches were integrated.
I'm sorry the answer is so generic, but I think you're best off with writing a small custom shell script for what you want.
Background
We use a central repository model to coordinate code submissions between all the developers on my team. Our automated nightly build system has a code submission cut-off of 3AM each morning, when it pulls the latest code from the central repo to its own local repository.
Some weeks ago, a build was performed that included Revision 1 of the repo. At that time, the build system did not in any way track the revision of the repository that was used to perform the build (it does now, thankfully).
-+------- Build Cut-Off Time
|
|
O Revision 1
An hour before the build cut-off time, a developer branched off the repository and committed a new revision in their own local copy. They did NOT push it back to the central repo before the cut-off and so it was not included in the build. This would be Revision 2 in the graph below.
-+------- Build Cut-Off Time
|
| O Revision 2
| |
| |
|/
|
O Revision 1
An hour after the build, the developer pushed their changes back to the central repo.
O Revision 3
|\
| |
-+-+----- Build Cut-Off Time
| |
| O Revision 2
| |
| |
|/
|
O Revision 1
So, Revision 1 made it into the build, while the changes in Revision 2 would've been included in the following morning's build (as part of Revision 3). So far, so good.
Problem
Now, today, I want to reconstruct the original build. The seemingly obvious steps to do this would be to
determine the revision that was in the original build,
update to that revision, and
perform the build.
The problem comes with Step 1. In the absence of a separately recorded repository revision, how can I definitively determine what revision of the repo was used in the original build? All revisions are on the same named branch and no tags are used.
The log command
hg log --date "<cutoff_of_original_build" --limit 1
gives Revision 2 - not Revision 1, which was in the original build!
Now, I understand why it does this - Revision 2 is now the revision closest to the build cut-off time - but it doesn't change the fact that I've failed to identify the correct revision on which to rebuild.
Thus, if I can't use the --date option of the log command to find the correct historical version, what other means are available to determine the correct one?
Considering whatever history might have been in the undo files is gone by now (the only thing I can think of that could give an indication), I think the only way to narrow it down to a specific revision will be a brute force approach.
If the range of possible revisions is a bit large and the product of building changes in size or other non-date aspect that is linear or near enough to linear, you may be able to use the bisect command to basically do a binary search to narrow down what revision you're looking for (or maybe just get close to it). At each revision that bisect stops to test, you would build at that revision and test whatever aspect you're using to compare against what the scheduled build produced that night. Might not even require building, depending on the test.
If it really is as simple as the graph you depict and the range of possibilities is short, you could just start from the latest revision it might be and walk backwards a few revisions, testing against the original build.
As for a definitive test comparing the two builds, hashing the test build and comparing it to a hash of the original build might work. If a compile on the nightly build machine and a compile on your machine of the same revision do not produce binary-identical builds, you may have to use binary diffing (such as with xdelta or bsdiff) and look for the smallest diff.
Mercurial does not have the information you want:
Mercurial does not, out of the box, make it its business to log and track every action performed regarding a repository, such as push, pull, update. If it did, it would be producing a lot of logging information. It does make available hooks that can be used to do that if one so desires.
It also does not care what you do with the contents of the working directory, such as opening files or compiling, so of course it is not going to track that at all. It's simply not what Mercurial does.
It was a mistake to not know exactly what the scheduled build was building. You agree implicitly because you now log that very information. The lack of that information before has simply come back to bite you, and there is no easy way out of it. Mercurial does not have the information you need. If the central repo is just a shared directory rather than a web-hosted repository that might have tracked activity, the only information about what was built is in the compiled version. Whether it is some metadata declared in the source that becomes part of the build, a naive aspect like filesize, or you truly are stuck hashing files, you can't get your answer without some effort.
Maybe you don't need to test every revision; there may be revisions you can be certain are not candidates. Knowing the time of the compile is merely a factor as the upper bound on the range of revisions to test. You know that revisions after that time could not possibly be candidates. What you don't know is what was pushed to the server at the time the build server pulled from it. But you do know that revisions from that day are the most likely. You also know that revisions in parallel unnamed branches are less-likely candidates than linear revisions and merges. If there are a lot of parallel unnamed branches and you know all your developers merge in a particular way, you might know whether the revisions under parent1 or parent2 should be tested based.
Maybe you don't even need to compile if there is metadata you can parse from the source code to compare with what you know about the specific build.
And you can automate your search. It would be easiest to do so with a linear search: less heuristics to design.
The bottom line is simply that Mercurial does not have a magic button to help in this case.
Apologies, it's probably bad form to answer one's own question, but there wasn't enough room to properly respond in a comment box.
To Joel, a couple of things:
First - and I mean this sincerely - thanks for your response. You provided an option that was considered, but which was ultimately rejected because it would be too complex to apply to my build environment.
Second, you got a little preachy there. In the question, it was understood that because a separately recorded repository revision was absent, there would be 'some effort' to figure out the correct revision. In a response to Lance's comment (above), I agree that recording the 40-byte repository hash is the 'correct' way of archiving the necessary build info. However, this question was about what CAN be done IF you do not have that information.
To be clear, I posted my question on StackOverflow for two reasons:
I figured that others must have run into this situation before and that, perhaps, someone may have determined a means to get at the requisite information. So, it was worth a shot.
Information sharing. If others run into this problem in the future, they will have an online reference that clearly explained the problem and discussed viable options for remediation.
Solution
In the end, perhaps my greatest thanks should go to Chris Morgan, who got me thinking to use the central server's mercurial-server logs. Using those logs, and some scripting, I was able to definitively determine the set of revisions that were pushed to the central repository at the time of the build. So, my thanks to Chris and to everyone else who responded.
As Joel said, it is not possible. However there are certain solutions that can help you:
maintain a database of nightly build revisions (date + changeset id)
build server can automatically tag revision it is based on (nightly/)
switch to Bazaar, it manages version numbers differently (branched versions are in form of REVISION_FORKED.BRANCH_NUMBER.BRANCH_REVISION so your change number 2 would be 1.1.1
I am working at a company which uses cvs for version control.
We develop and maintain an online system involving around a hundred executables - which share large amounts of code, and a large number of supporting files.
We have a head branch, and live branches taken from the head branch. The live branches represent major releases which are released about every three months.
In addition there are a numerous daily bug fixes which must be applied to both the live branch - so they can be take to the live environment immeadiatley, and merged back to the head branch, so they will be in the next major release.
Our most obvious difficulty is with the daily fixes. As we have many daily modifications there are always multiple changes on the testing environment. Often when the executables are rebuilt for one task, untested changes to shared code get included in the build and taken to the live environment.
It seems to me we need some tools to better manage changesets.
I'm not the person who does the builds, so I am hoping to find a straight forward process for managing this, as it will make it easier for me get the build manager interested in adopting it.
I think what you need is a change in repository layout. If I understand correctly, your repository looks like this:
Mainline
|
-- Live branch January (v 1.0)
|
-- Live branch April (v 2.0)
|
-- Live branch July (v 3.0)
So each of the branches contains all your sites (hundreds) as well as folders for shared code.
There is no scientific way to exactly tell the chance of an error appearing after a release but lets have a look at the two most important factors:
Number of code lines commited per time-unit. You can not / will not want to globaly change this as it is the developer's productivity output.
Test-Coverage, aka how often gets code executed BEFORE beeing live and how much of your codebase is involved. This could easily be change by giving people more time to test before a release or by implementing automated tests. Its a ressources issue.
If your company neither wants to spend money on extra testing nor decrease release frequency (not neccessarily productivity!) you will indeed have to find a way to release less changes, effecively decreasing the number of changed lines of code per release.
As a result of this insight, having all developers committing into the same branch and going live from there multiple times a day doesn't sound like a good idea, does it?
You want increased Isolation.
Isolation in most version controll systems is implemented by
Incrementing revision numbers per atomic commit
Branching
You could try to implement a solution that packs changes from multiple revisions into release-packages a bit like the version controll system "perforce" does it. I wouldn't do that though as branching is allmost allways easier. Keep the KISS principle in mind.
So how could branching help?
You could try to Isolate change that have to go live today from changes that might have to go live tomorrow or next week.
Iteration Branches
Mainline
|
-- Live branch July (v 3.0)
|
-- Monday (may result in releases 3.0.1 - 3.0.5)
|
-- Thuesday (may result in releases 3.0.6 - 3.0.8)
|
-- Wednesday (may result in releases 3.0.9 - 3.0.14)
People need to spend more thought about "targeting" their changes to the right release but it could lead to not-so-urgent changes (especialy on shared/library code) staying longer OUTSIDE of a release and inside the live branch where by chance or systematic testing they could be discovered before going live (see factor test coverage).
Additional merging down is required of course and sometimes cherrypicking of changes out of the live-branch into the daily-branch.
Now please dont take me too literaly with the daily branches. In my company we have 2-week iterations and for each iteration a release branch and it is enough overhead allready to maintain that branch.
Instead of isolating by day you could try to isolate by product/site.
Project Branches
Mainline
|
-- Live branch July (v 3.0)
|
-- Mysite-A (released when something in A changed and only released to the destination of A)
|
-- Mysite-B
|
-- Mysite-C
In this scenario the code of the single site AND all needed shared code and libraries would reside in such a Site-branch.
If shared code has to be altered for something to work within site A you only change the shared code in site A. You also merge the change down so anyone can catch up on your changes. Catching up cycles may be a lot longer than releases so the code has time to "ripe".
In your deploy/build process you have to make sure that the shared code of site-A does NOT overwrite the shared code site-B uses of course. You are effectivly "forking" your shared code with all implication (incompatibility, overhead for integrating team-changes).
Once in a while there should be forced merges down to the live-branch (you might want to rename that then too) to integrate all changes that have been done on shared code. Your 3-month iteration will force you to that anyway I guess but you might find out that 3 months is too long for hassle-free integration.
The third approach is the most extrem.
Project & Iteration Branches
Mainline
|
-- Live branch July (v 3.0)
|
-- Mysite-A
|
-- Week 1
|
-- Week 2
|
-- Week 3
|
-- Mysite-B
|
-- Week 1
|
-- Week 2
|
-- Week 3
|
-- Mysite-C
|
-- Week 1
|
-- Week 2
|
-- Week 3
This certainly brings a huge ammount of overhead and potential headache if you are not paying attention. On the good side you can very accuratly deploy only the changes that are needed NOW for THIS Project/Site.
I hope this all gives you some ideas.
Applied source controll is alot about risk controll for increased product quality.
While the decision what level of quality your company wants to deliver might not be in your hands, knowing it will help you deciding what changes to suggest. Might turn out your customers are adequatly content with your quality and further efforts to increase it do not amortize.
Good luck.
Christoph