CVS checkout vs. export
Hello,
It seems that when checking out a project from CVS, the agent actually runs "cvs export". Or probably it does checkout but then removes all "CVS" subdirectories.
Is there a way to do ordinary checkout? I'd like to have projects checked out with "cvs checkout -P".
The reason I need this is that I have a separate cvs module for configuration management. During the build some files get updated (for example, with the new build number) and need to be committed to the cvs. This is done from ant, but it is not possible without proper initial checkout.
I also have another concern in regards with this scenario. I have this excerpt in the configuration file:
]]>
Am I right that the abovementioned commit of the configuration files into the repository would trigger the build? That would result in a really continuous integration.
It would be great if I could specify which vcs roots should trigger the build.
Please sign in to leave a comment.
It seems you're using "checkout on server" functionality. In this case no
any cvs commands run on server, all files (or changed ones) are beeing
tranfering from the server to the selected agent. You can disable
checkout-on-server option and perform 'cvs co' youself (using bootstrap
build script) on the client if you have to submit some files during the
build process.
So you can specify vcs roots which have to trigger builds and ignore other
roots.
"Igor Sereda" <no_reply@jetbrains.com> wrote in message
news:20407184.1149525827996.JavaMail.itn@is.intellij.net...
>
>
>
>
>
>
>
What other files are commited?
Commiting the file with the build number can be avoided by using the build
number provided by the build server ("next.build.id" property in Ant) instead
of the build number stored in a file. As additional advantage, the build
number provided by the server is visible in build server UI.
Valentin Kipiatkov
Chief Scientist, Vice President of Product Development
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
Thanks for the answer!
The other files are obfuscator maps.
As for the build number, I'd rather have my own build number displayed on TeamWare page. Having my own build number gives me the following advantages:
- Control over the build number. I can set it to whatever value I like whenever needed.
- My own form for build number. For example, a release from a branch will have build number like 1792.43.
- VCS storage for build number: versioning, backup.
For me to consider using TeamWare build number it has to beat these advantages. It may be possible, I think, with some API. But again, I'd rather have my own build number assigned to a build somehow.
Best regards,
Igor
Thanks!
I'll try that.
Oh, I missed the corresponding Administrative page. Seems like the first two points are successfully addressed. That's cool!
Just for clarification:
Does TW provide a setting for "bootstrap" script? Or is it just an ordinary build script that does the checkout and that is run by TW - without knowledge that it is being "bootstrap"?
Igor Sereda wrote:
There is no special "bootstrap" script. You simply specify either text of the
build script or path to the script, located on the agent machine.
The real issue is, whether you'll use TeamServer's checkout-on-server
feature. If yes (default), you can simply set "build.xml" as value of the build
script. If no, your own script should take responsibility for obtaining your
sources to the agent. In such situation you have to write 'bootstrap' checkout
code first, and then probably call 'real' build script checked out from VCS.
Hope this helps,
KIR
--
Kirill Maximov
Software Developer
JetBrains, Inc.
http://www.jetbrains.com
"Develop with pleasure!"
Thanks!
It works now. That's cool :))
By the way: because now the build is running in /tmp partition, which is allocated in virtual memory, the build was ~25% quicker. Something to think about :)
Regards,
Igor
Do you store them in the version control? Why? I believe obfuscator maps
should be build "artefacts" (notion supported by our build server).
Valentin Kipiatkov
Chief Scientist, Vice President of Product Development
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"
You're right, obfuscator maps are "artifacts" as well as binaries, in a sense that they are a product of a build process. But there's a difference.
You normally should be able to re-build deliverable binaries from the same sources. The result must not be functionally different, in many cases it will be byte-to-byte equal to the original. That's important because we might want to repeat a problem that a customer has and all we know is the application build number.
The obfuscator maps, however, may vary from build to build in a random way since an obfuscator does not have to produce the same mapping from the same sources. That means if we rebuild obfuscator maps they will not be applicable to stack traces we receive from users that run the original version.
I'm saying all this to point out that for all builds that are delivered we must keep obfuscator maps somewhere. And why not keep them in VCS? It very convenient, because it is easily automated, you don't have to deal with zillion files of the same type, you have a well-known way to extract a given map, maps fall into overall repository backup procedure. I simply don't see the alternative :)
Where do you store obfuscator maps?
Hello Igor,
We store obfuscation logs along with binaries produced by the build. In fact,
we had never have to rebuild the build from a snapshot in VCS.
-
Maxim Shafirov
JetBrains, Inc
http://www.jetbrains.com
"Develop with pleasure!"