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.

11 comments
Comment actions Permalink


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...

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:

>

<build-triggers>
<vcs />
</build-triggers>

>

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.



0
Comment actions Permalink

During the build some files get updated (for
example, with the new build number) and need to be committed to the
cvs.


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!"

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:

<build-triggers>
<vcs />
</build-triggers>
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.



0
Comment actions Permalink

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

0
Comment actions Permalink

Thanks!

I'll try that.

0
Comment actions Permalink

Oh, I missed the corresponding Administrative page. Seems like the first two points are successfully addressed. That's cool!

0
Comment actions Permalink

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"?

0
Comment actions Permalink

Igor Sereda wrote:

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"?


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!"

0
Comment actions Permalink

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

0
Comment actions Permalink

The other files are obfuscator maps.


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!"

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



0
Comment actions Permalink

Do you store them in the version control? Why? I
believe obfuscator maps
should be build "artefacts" (notion supported by our
build server).


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?

0
Comment actions Permalink

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!"


0

Please sign in to leave a comment.