> -----Original Message-----
> From: Robert Wenner [mailto:robert.wenner@atsec.com]
>
> On Tuesday 01 August 2006 13:53, Reedick, Andrew wrote:
> > a) You scare my inner CM child. The repository revision
> number(s) and
> > the code/workspace revision number(s) are not guaranteed to be the
> > same, so your build number is random.
>
> Why random?
> The working copy revision number is what he has checked out,
> which is what
> he will use as build number and as code to build from.
> If the working copy has no local modifications, that number
> is exactly
> what he needs.
> If he checks out a fresh working copy, he's fine as well.
Because he said:
Right now, I'm using a php script to call
'svn info --non-interative -R' on the repository url and sub-directory
(not a work area), and then just scanning for the highest value in the
repository for that subtree.
Which sounds like he's getting the build number from the
repository after the code has already been checked out. On a second
reading of OP's email, I'm not a 100% certain that that is the case.
Note to self, cut down on inner CM child's caffeine coefficient.
> > First, get the HEAD revision number of the project root using
> > "svn info url/project_root".
>
> Why not use svnversion, maybe in combination with a regex to
> just get one
> of the numbers?
Good point. I didn't even notice that svnversion existed until
now. =P OTOH, svnversion only works against the working copy. In my
experience, you should know what revision you want to build _before_ you
create the working copy...
> > You will probably want to make the build area readonly
> > to everyone but the build owner.
>
> Most compilers I know of want to create object files....
The build process would run as the build owner (ex: use sudo so
that regular users can kick off builds.) If you want build
repeatibility, it helps to prevent well intentioned developers from
being able to change things.
> Even if you do, the revision number can be fine if you say
> it's for the
> foo product because you will always know the root of the foo project.
An environment (QA, UAT, whatever) has build 1234. Can you tell
me where build 1234 came from, given this repository:
trunk/
branches/feature1
branches/feature2
branches/experimental_speed_improvements
branches/rel.1.0
branches/rel.1.1
Does QA/UAT have the trunk 1234 build, or the
experimental_speed_improvements 1234 build? If you're doing parallel
development, did build 1234 come from rel1.0, or rel.1.1? What if by
coincidence, both rel.1.0 and rel.1.1 each have a 1234 build? After
all, there's no rule preventing a user from checking in code spanning
multiple branches/trunk in one commit. (But there is a pre-commit hook
now...)
The revision number applies to the entire repository, and the
repository can easily contain more than one buildable code base. Hence
the need for the url + rev_num.
>
> One could include tags or branch names, though, even if only
> for marketing
> purposes ("beta 2").
Don't drag marketing into this. =O
> > If you are building from a workset, then you can use 'svn info
> > root_dir_of_workspace' to get the revision number. However, this
> > assumes that the entire workspace is on the same rev number
> and isn't a
> > mixed revision workspace.
>
> Which is somewhat unlikely, but that's what svnversion is for.
Correct. But, it's so much easier to just checkout cleanly
using a rev number and build that rev number (plus url.)
I'm approaching this from the CM side. If dev wants fuzzy dev
builds (for speed or continuous integration,) then that's ok. However,
when the time comes for a formal build and deployment to QA, fuzzy is
way too expensive and painful.
*****
The information transmitted is intended only for the person or entity to which it is addressed and may contain confidential, proprietary, and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from all computers. 162
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Aug 1 22:09:39 2006