 |
History
| Log In
|
|
|
|
Hi Christian,
I'm not sure that I completely follow. The new-born *.xml file that disappears, where does it come from? If you add it via your local working copy, it should be part of the build. Even if you only leave it in the "added" state. If it is not, then this is a bug. The -D option specifies a date for the checkout. Typically, that date will be very close to the current time, and so very close to the head. More importantly, that date will be the date for the revision of your local working directory after pulse updates. Unless there is a large time difference between when you trigger the personal build and when the build is bootstrapped, I would not expect there to be much of a difference? Any differences that do occur (resulting for a check in by someone else) is unlikely to be something that you want in the build?. If what I have said does not make much sense in the context of your query, then I have miss understood :), always possible. If so, can you please elaborate on what you are trying to achieve and how, and hopefully that will clarify things. Cheers, -Daniel Daniel,
What I'm trying to achieve is to build from a cvs _tagged_ _revision_. This tag is enough to uniquely identify all files going into our build, including the pulse xml project file. I can inject this tag by setting cvs.branch into the .pulse.properties file and this is confirmed in the cvs log file on the pulse server (option -r to cvs). Of course I'm cheating here since the tag used with cvs.branch here is not a branch, so this is where we're bending pulse's rules and we know it. If it was a real branch with pulse adding -D to cvs this works just fine. Unfortunately with a tag instead given to -r plus the always present -D result in a contradictory and/or confusing request to cvs which will refuse to check out any file with the 'new-born <file> has disappeared' whatever the argument is given to -D. What we would like to see is some way to turn off the -D option to cvs in this very specific case. I know pulse needs a date internally to track the build but we'd like just to drop the date (-D) to cvs and nothing else for this very specific case. In fact this was my expectation first time I tried the 'prompt for revision option' that we could just enter a standard cvs tag. Unfortunately the allowed revision right now is only a date which is not specific enough in our case to identify the source for a release. It's probably clearer now. Sorry not to have been more explicit about our pulse perversion attempt :-) Christian Hi Christian,
Ok, that clears things up. Let me have a chat with Jason to see what we can do to support this. Cheers, -Daniel Ok, it sounds like the best solution to this is to allow you to specify a standard TAG when prompted so that you can control what you build. It turns out that the necessary changes to make this happen were not as difficult as I had expected, so it is done and will be available with the next release.
If you need something different, please let me know. Cheers, -Daniel Cool! Looking forward for the next release (1.2.38?).
Hi Christian,
Just wanted to let you know that 1.2.38 is now available for download. Cheers, -Daniel Just want to say that it works great!! We have now one release process which is totally encapsulated within a pulse script with the help of a bunch of python scripts to run blessing tests and of course this new build-from-tag capability.
Now the only missing thing, and this is very minor, would be to display the tag instead of 'revision null' when you pick the 'changes' tab for a build. We now run an extra command with 'cvs stat' and a pulse regex to get this info, so it's not like we're left in the cold without this. Hi Christian,
Glad to hear that things are working for you now. The null revision sounds like a bug. I will raise this as a separate jira ticket. ( Cheers, -Daniel |
||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Resolved
Major
Allow tags to be used when specifying revisions for CVS builds
We know from
CIB-1150that pulse has a date-based revision scheme to keep track of builds and that cvs tag do no fit that scheme. We are now trying to build SDK releases through personal builds and the only thing in our way is the -D option put by pulse when checking out the project pulse file resulting in a "new-born *.xml file disappered" from cvs.If there was an option (preferably a pulse dev client option) to quiet the cvs -D option (not just for the pulse file but the whole bootstrap as well) but doing everything else the same including pulse internal revision-date we think we could achieve what we want.
Does the above makes sense? Is there a quick way to make this works?