Re: Putting the tag name in the tagged code

[Bob Hiestand <bo...@gmail.com>]

On 2/28/07, jason marshall <jd...@gmail.com> wrote:

> Perhaps I should also point out that I'm a library writer, so my
> binaries go into someone else's binaries.  I get bug reports from my
> users, and from their users.  It's a challenge to make sure that my
> users are keeping up-to-date with patches, so the number of bug
> reports are lower, so I can tell a known issue from a regression, and
> so I don't get pulled into every end-user conversation.

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?

Thank you,

Bob

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Putting the tag name in the tagged code

[Bryant Eastham <be...@pewla.us.pewg.panasonic.com>]

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 <bo...@gmail.com> wrote:
> On 3/5/07, jason marshall <jd...@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

Re: Putting the tag name in the tagged code

[jason marshall <jd...@gmail.com>]

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 <bo...@gmail.com> wrote:
> On 3/5/07, jason marshall <jd...@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

Re: Putting the tag name in the tagged code

[Bob Hiestand <bo...@gmail.com>]

On 3/5/07, jason marshall <jd...@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

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org

Re: Putting the tag name in the tagged code

[jason marshall <jd...@gmail.com>]

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.


I did find a way to get what I wanted.  Almost.  'svn copy <dir>
<URL>' is intended to do a branch of the working directory, not the
revision the working directory is based on.  Fortunately, my
Continuous Integration tool uses this form of the command to tag
builds.

Unfortunately, it means I'm open to another class of bad tagging.
Notwithstanding that little hitch, at least the code builds as tested,
and the forensic trail is clear if something actually is amiss with
the tagging.  I just have to enforce a convention not to change any
checkout artifacts in the build process.  Since this is a perfectly
reasonable convention regardless, I'm not too broken up about it.



Thanks,
-Jason



On 3/5/07, Bob Hiestand <bo...@gmail.com> wrote:
> On 2/28/07, jason marshall <jd...@gmail.com> wrote:
>
> > Perhaps I should also point out that I'm a library writer, so my
> > binaries go into someone else's binaries.  I get bug reports from my
> > users, and from their users.  It's a challenge to make sure that my
> > users are keeping up-to-date with patches, so the number of bug
> > reports are lower, so I can tell a known issue from a regression, and
> > so I don't get pulled into every end-user conversation.
>
> 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?
>
> Thank you,
>
> Bob
>


-- 
- Jason

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org