Re: [BBv2] support for version control systems

From: Reece Dunn (msclrhd_at_[hidden])
Date: 2005-09-17 04:54:24

Andrey Melnikov wrote:
> Reece Dunn wrote:
> [snip]
>> ...> echo Bugfixes for foo > desc.txt
>> ...> bjam checkin-cvs branch=RC_1_34 desc=desc.txt
>>
>>or
>>
>> ...> bjam diff-cvs # diff files with latest version
>> ...> bjam diff compare-with=...
>>
>>I am not sure how these will work with BBv2, but this is the sort of 
>>thing I am referring to.
>>
> Do you mean you want a unified command line interface to version control 
> systems?

In the same sense that BB/SCons offer a unified interface to C++ 
compilers (and tools in general). Don't forget that I am just generating 
ideas. I have absolutely no idea what the final syntax/usage would be. 
The *really* big thing would be where you could to:

# Jamfile

update sync-cvs : dir=. : <toolset>cvs ;

exe regression-test : ... //sync-cvs ;

and BB will automatically sync with the latest code from CVS. Or you 
could do:

bjam ... label=Build10

to automatically sync with Build10 of the codebase and perform the tests 
with that. You could also do this with a project build so you could go 
back to earlier builds of that product and run tests for it.

You could even use this to automate logging the changelist number/date 
that the build occurred, so you have a log of what version of the 
codebase you are using.

Also, if you wanted to go all out, you could add the build log into the 
VCS after the build has finished.

I am not proposing that any of the syntaxes I have shown is the one we 
should use, but showing how you could leverage such a system to either 
automate it in the build (as above), or use it to get a unified 
(simpler) command-line interface. This would be a major win as I don't 
have to spend time looking up the commandline to get an RCS diff, for 
example.

However, that all said, I am not sure exactly how this all fits into the 
BB model. Think of this as the concept phase: what do people want out of 
this? How can we make those tasks easier?

For any major development work, you need to have some sort of VCS. This 
will be tied directly to the develop-checkin-build-test cycle as well as 
the nighly builds and test reports. Being able then to tie the VCS 
management into the build system gives a developer greater power.

For example, if someone said there was a serious crash in 
Boost.Filesystem for example in version 1.30 with gcc, you could do:

bjam gcc debug label=1_30

build the sample code you were given and check out the issue. Once 
located, you can see if it is an issue with the current codebase.

Or if you were developing on Firefox and someone said there was an issue 
with the 2005-08-20/9:15 build, where you wouldn't necessarily have a 
binary snapshot. It would be easier just to tell the buildsystem to 
build the product using a specific version from the VCS.

- Reece