Re: [jamboost] [BBv2] support for version control systems

From: Steven Knight (knight_at_[hidden])
Date: 2005-09-18 14:21:24

Hi Volodya--

>> Most commercial software uses some form of version control system to
>> track software. Open source projects and even "home grown" projects use
>> VCS of some form or other.
>>
>> My question is this: is there interest in VCS support for performing
>> options like checkout and diff from inside BBv2?
>>
>> Support would include the following VCS systems: CVS, subversion and
>> perforce.

Subversion is an interesting case because, unlike other SCM systems
(or at least the others mentioned), the directory is the atomic unit
of checkout--or was last I looked. Since a build tool wants to track
dependencies between individual files, there's a slight granularity
mismatch.

We've had an experimental Subversion module in SCons for a long time
(since we first rolled out VCS support), but it's never been officially
supported because no one had enough of an itch to define exactly
what the *right* behavior is when you determine that a single file
needs updating ubt you have to check out a whole directory to get it.
Do you go ahead and check out the whole directory? Do you just grab a
read-only, non-checked-out copy of the file in question? Or do you do
something else entirely?

Not hard issues, but it struck me as the sort of thing it's easy to get
wrong if you just grab for an easy answer. And I like I said, no
one's had enough of an itch...

>> I don't have anything available yet, just probing interest.
>
> We talked about it once with Steven Knight (SCons developer), when he was
> adding Subversion support to SCons. I never understood why adding svn support
> to a build tool makes any sense, and still don't understand it now.

The underlying idea of having the build tool check out files
automatically goes back to Make, of course, which still to this day
has built-in support for checking out source files from SCCS and RCS.
Make essentially implements it with pattern rules that get triggered if,
say, the foo.c file doesn't exist in your local directory, but either
the underlying SCCS/s.foo.c or RCS/foo.c,v file does.

The workflow this supports is to only have to 'sccs edit' or 'co' the
pieces you're working on, and to let your build worry about all the
other stuff. This was especially useful if you were not working from
a central project repository, but on a standalone project with your own
copies of the SCCS or RCCS files in the local directory.

> The biggest questions is: to use Boost.Build to checkout anything at all, you
> need Jamfile, and you surely need to keep everything in Subversion, so you
> need to checkout Jamfile first. And if you checkout Jamfile, why don't you
> checkout all of your project?

You're right that the workflow doesn't make as much sense (or isn't as
widespread) in this day of checking out projects across the net from
CVS or Subversion or what have. Note, however, the BitKeeper *does*
use this model.

Workflow issues aside, a lot of people still find it useful to let the
build tool handle the details of what needs to be checked out, especially
when working with subsets of big source trees. Yeah, you can maintain
those subset lists by hand as CVS modules or what have you, but those
lists are almost guaranteed to get out of date as code base changes.
If the build tool can just fetch what's needed as it's needed, that's
one less thing to worry about...

--SK