RE: integrating Subversion with a build tool?

In my point of view, there is nothing wrong with this model, but SVN makes
the model work better and more reliable. There is no link (yet) from SVN to
an issue-tracking system like ClearCase links with ClearQuest. But in my
view, it would work very much the same with SVN.

Only better, because of atomic commits.

When the build process starts, the build tool checks out / updates to the
most recent version of it's designated stable branch.

It then has a snapshot that it works from.

During the checkout/update, SVN guarantees that nothing changes to the files
- the revision number of the repository is determined at start of the
checkout, and that is what you'll see even if several checkins happen during
the checkout of the build-tool. This is where SVN is way, way, way superior
to CVS or Clear-as-mud-Case.

For the duration of the entire build and test cycle the build-tool doesn't
have to check the version control system anymore, because it knows that it
has a full and complete version of a particular revision.
Dependancy checking and determining what needs to be built happens now as
normally, but without going back to your version control system.
A missing file means a build-failure, not an indication that it needs to be
fetched from svn.

When the build and test cycle is complete, the status reports can be mailed
to whomever and the cycle begins from start, with a new 'svn up' to get all
changes since the last build.

--Tim

-----Original Message-----
From: Paul Lussier [mailto:pll@lanminds.com]
Sent: maandag 24 maart 2003 18:24
To: Greg Hudson
Cc: Steven Knight; dev@subversion.tigris.org
Subject: Re: integrating Subversion with a build tool?

In a message dated: 24 Mar 2003 12:05:38 EST
Greg Hudson said:

>On Sun, 2003-03-23 at 14:01, Steven Knight wrote:
>> Umm... I understand *how* Subversion works. The problem is trying to
>> make Subversion checkouts work with an already well-established model
>> for the interaction of build tools and (other) source code management
>> system.
>
>I tend to believe that this model is rarely used (contrary to your
>initial assertion) and fundamentally flawed.

[...snip...]

>Now I have foo.c and bar.c from two different revisions, which
>potentially aren't consistent with each other.

In well run shops that I've been in, I tend to see the build
environment configured such that it always checks out of a stable
branch. Usually, all developers will develop in private branches or
views, then merge with main line which also may be a private branch.
The build tool with then only build against that 'stable'branch.

Effectively, the build tool has it's own private branch that no one
will be checking into, since everyone develops against their own
branches, and only when a merge into the build branch takes place,
will a build get run. Also, usually there's some policy in place
which dictates that you can't commit during a build. Whether it's
just an unwritten rule, or enforced using triggers/scripts, etc.

This is done all the time in ClearCase, and with their UCM
business-rules based developement paradigm, you also get issues
linked to check-ins/outs which trigger actions, which trigger builds,
which trigger new issues based on build results, etc. It's (in
theory) a giant developmental feedback-loop.

(of course, it also costs a fortune, doesn't always do what you need/
want it to, and seems like total over-kill for most small shops. But
that doesn't stop it from being a good idea :)

-- 
Seeya,
Paul
--
Key fingerprint = 1660 FECC 5D21 D286 F853  E808 BB07 9239 53F1 28EE
	It may look like I'm just sitting here doing nothing,
   but I'm really actively waiting for all my problems to go away.
	 If you're not having fun, you're not doing it right!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org