Re: Putting the tag name in the tagged code

Jason-
[Since you CCed the list on my last private response, I'll include the
list now].

I guess I am still confused on this issue. I completely agree with
removing humans from the loop. It seems like the previous arguments
about having all the information available still apply.

Without starting yet another discussion about product revisions vs.
subversion revisions, here is what we do:

1. In each deliverable directory we have a "version" file (version
controlled) that contains the base revision (A.B) of that component.

2. Our build targets look for a file build_info (unversioned), and if it
exists it defines symbols based on its contents. We have rules defined
that will "stamp" these symbols (in different flavors) into all types of
source files (like word documents, source files, resource files, etc.).
Of course the file is copied in the process, creating a new unversioned
file so that commits are not polluted. These modified src files are
deleted with "make dist-clean", but build_info is *not*.

3. If build_info doesn't exist, it is created. If svn is available
(building from a WD), then use "svnversion" to get the revision. This
gets added to the base version to form the official version (A.B.R). If
svn is not available and build_info doesn't exist, it becomes invalid
(A.B.0).

4. Source distributions ship build_info as it was created during
dist-src. They no longer require svn, because they don't need to rebuild
a file that exists. We also allow "descriptions" to be added to
build_info (A1, B1, RC2, etc.) so that files that take human visible
versions will get something like "Revision A.B.R RC2".

All of this allows us to move from trunk to branch, fix problems, go to
release candidate, and then from release candidate to final release
without the revision changing from RC to Final (it just uses the tags).

We are doing exactly what you mention - shipping libraries to
developers. Whether they get one of our pre-built libraries, build from
a source distribution or do an svn co and build themselves they will get
the same revision from the same source. We also have the ability to tag
files (like release notes) with the revision and branch information. We
then have the benefit of not only knowing the revision (svn revision -
the "R" of A.B.R) but also the branch that the component came from. We
have not had a problem yet identifying the source of a distribution.

The trick is making sure that whenever you don't have a WD that your
version information is available. This only implies that some process
(ours is completely automated) that *did* have a WD used it save/build
the version information during distribution.

If you are not willing even to require that level of process, then I
suggest that you more clearly state your requirements *and* assumptions.

--
Bryant Eastham beastham@pewla.us.pewg.panasonic.com
Chief Architect
Panasonic Electric Works Laboratory of America, Inc. , Salt Lake City
Lab
4525 South Wasatch Blvd., Suite 100, Salt Lake City, Utah 84124
Phone : 801.993.7124  Fax: 801.993.7260
MEW Intranet: https://pewla.mew.com/index.php/User:Beastham
 
-----Original Message-----
From: jason marshall [mailto:jdmarshall@gmail.com] 
Sent: Tuesday, March 06, 2007 11:08 AM
To: Bob Hiestand
Cc: users@subversion.tigris.org
Subject: Re: Putting the tag name in the tagged code
Humans transpose numbers.  Or forget which tag they were given.
The only thing worse than no data is bad data.  I'd rather have
something called 'foo.jar' that was build 1.23 than have something
called foo-1.32.jar that's actually build 1.23.  At least I know up
front that I have some digging to do.
-Jason
On 3/6/07, Bob Hiestand <bob.hiestand@gmail.com> wrote:
> On 3/5/07, jason marshall <jdmarshall@gmail.com> wrote:
>
> > > When you run your build process, or use a task in your process to
> > > extract the tree, you obviously know which branch/tag you're
building.
> > >  Why not generate an unversioned file in your sandbox at that
point
> > > and use it during builds?
>
> > Because I don't 'obviously' know that information.  If it's a
working
> > directory, I could pull it out of the .svn information, sure.  But
if
> > it's a source distribution, or if I can't rely on svn, then it's a
> > manual process, and the whole point of the exercise is to take the
> > human out of the loop.
>
> A human somewhere makes a choice when extracting the source from SVN
> or any source control system to specify the tag.  The build systems
> with which I currently work (CVS-based, incidentally) are given a tag
> as input, and extract, build, and package the resulting components.
> Included in that activity is recording the given tag where it is
> desired.
>
> In any event, it sounds like you're covered.
>
> Thank you,
>
> Bob
>
-- 
- Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org