You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by jason marshall <jd...@gmail.com> on 2007/02/28 07:56:57 UTC
Putting the tag name in the tagged code
I have a requirement for my code repository that I don't think is
exotic, or honestly all that uncommon. I need to get accurate version
information into any binary built from an SVN tag directory, for
purposes of version tracking and customer support.
I can certainly accomplish this with pre-built binaries. Many
Continuous Integration tools have facilities for doing this (and
generating the tags to begin with), but that only helps when I'm doing
a binary distribution. Is there a way to accomplish the same thing
(automatically!) with a source distribution?
The general consensus seems to be that it's both unwise and fairly
brittle to have an on-commit modification (such as code beautifying)
to the source tree. However, with a tag we're generally NOT expecting
anyone to update it, and at least in our case it's being created
directly in the repository, so there is no repos/working directory
inconsistency to mitigate.
So my question is, how best should I accomplish this? A pre-commit
hook? Groveling around in the svn info data to extract the tag
directory or revision number information?
Any suggestions would be appreciated. Pointers to existing solutions
to this problem would be superb.
Thanks,
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
Posted by Ulrich Eckhardt <ec...@satorlaser.com>.
On Wednesday 28 February 2007 08:56, jason marshall wrote:
> I have a requirement for my code repository that I don't think is
> exotic, or honestly all that uncommon. I need to get accurate version
> information into any binary built from an SVN tag directory, for
> purposes of version tracking and customer support.
>
> I can certainly accomplish this with pre-built binaries. Many
> Continuous Integration tools have facilities for doing this (and
> generating the tags to begin with), but that only helps when I'm doing
> a binary distribution. Is there a way to accomplish the same thing
> (automatically!) with a source distribution?
>
> The general consensus seems to be that it's both unwise and fairly
> brittle to have an on-commit modification (such as code beautifying)
> to the source tree. However, with a tag we're generally NOT expecting
> anyone to update it, and at least in our case it's being created
> directly in the repository, so there is no repos/working directory
> inconsistency to mitigate.
Hmmm, what is it that you can't achieve with the existing placeholders that
SVN can replace in text files? The path and revision within a repository
should be enough, right?
Uli
--
ML: http://subversion.tigris.org/mailing-list-guidelines.html
FAQ: http://subversion.tigris.org/faq.html
Docs: http://svnbook.red-bean.com/
Sator Laser GmbH
Geschäftsführer: Ronald Boers Steuernummer: 02/892/02900
Amtsgericht Hamburg HR B62 932 USt-Id.Nr.: DE183047360
**************************************************************************************
Visit our website at <http://www.satorlaser.de/>
**************************************************************************************
Diese E-Mail einschließlich sämtlicher Anhänge ist nur für den Adressaten bestimmt und kann vertrauliche Informationen enthalten. Bitte benachrichtigen Sie den Absender umgehend, falls Sie nicht der beabsichtigte Empfänger sein sollten. Die E-Mail ist in diesem Fall zu löschen und darf weder gelesen, weitergeleitet, veröffentlicht oder anderweitig benutzt werden.
E-Mails können durch Dritte gelesen werden und Viren sowie nichtautorisierte Änderungen enthalten. Sator Laser GmbH ist für diese Folgen nicht verantwortlich.
**************************************************************************************
---------------------------------------------------------------------
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
Posted by 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
Posted by 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
Posted by 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
Posted by 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
Re: Putting the tag name in the tagged code
Posted by 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
Posted by jason marshall <jd...@gmail.com>.
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.
-Jason
On 2/28/07, jason marshall <jd...@gmail.com> wrote:
> On 2/28/07, Bryant Eastham <be...@pewla.us.pewg.panasonic.com> wrote:
> > Jason-
> >
> > I believe that you are confusing the requirements of version control
> > with the issues of distribution tracking.
>
> Entirely possible, but I think the fact that the FAQ bears a question
> very close to what I'm asking indicates that's not entirely true.
> Unfortunately the FAQ answer reads more like an apology than a
> rationale for why nobody would want to do that.
>
>
> > Obviously the problem doesn't exist for people that have access the SVN
> > repository - they can just ask and they will know exactly what tag they
> > are working with.
>
> Actually, the problem ONLY exists for people that take the code from
> the repository. I have a little website where I publish the artifacts
> from a Continuous Integration tool. It tags and bags all of the
> builds (including the ones determined to be important), and everyone
> who uses that site always knows exactly which build of the code
> they're running.
>
> It's the people who want to grab the code from the repository (or
> can't access the website, for various sad reasons) that can't get the
> build artifacts as originally generated. They have to re-generate
> them through the build tool (in this case, Ant). But I have no way of
> injecting the build number into the build scripts, short of a manual
> process. I use the tools I use because they take the human factor out
> of things that people are bad at (like bookkeeping), and this throws
> the human (me) right back into the fray.
>
>
> -Jason
>
>
>
> > It seems that your issue is getting some level of information to people
> > that obtain your source through some other method. If so, I would try to
> > solve the problem at the point of creation of the distribution. What
> > process do you use at that point? A Makefile with "make dist-src"? Some
> > manual process? It seems that is the appropriate place to generate such
> > other reports.
> >
> > For example, I can do a "make dist-clean; make dist-src" in our tree,
> > and it will do exactly what I need. Part of that process is creating a
> > tagged README, License, and version files. Those files are always static
> > in SVN, dynamic in the distribution.
> >
> > The system is completely automatic, and it works for any src tree
> > anywhere (trunk, tag, branch) which has benefits internally as well as
> > externally. As it turns out this is the same solution used to get the
> > information into our binaries.
> >
> > Just my .02. If you are interested I can forward the Makefile lines, but
> > it is all pretty easy.
> >
> > --
> > 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: Wednesday, February 28, 2007 4:57 PM
> > To: users@subversion.tigris.org
> > Subject: Putting the tag name in the tagged code
> >
> > I have a requirement for my code repository that I don't think is
> > exotic, or honestly all that uncommon. I need to get accurate version
> > information into any binary built from an SVN tag directory, for
> > purposes of version tracking and customer support.
> >
> > I can certainly accomplish this with pre-built binaries. Many
> > Continuous Integration tools have facilities for doing this (and
> > generating the tags to begin with), but that only helps when I'm doing
> > a binary distribution. Is there a way to accomplish the same thing
> > (automatically!) with a source distribution?
> >
> > The general consensus seems to be that it's both unwise and fairly
> > brittle to have an on-commit modification (such as code beautifying)
> > to the source tree. However, with a tag we're generally NOT expecting
> > anyone to update it, and at least in our case it's being created
> > directly in the repository, so there is no repos/working directory
> > inconsistency to mitigate.
> >
> >
> > So my question is, how best should I accomplish this? A pre-commit
> > hook? Groveling around in the svn info data to extract the tag
> > directory or revision number information?
> >
> > Any suggestions would be appreciated. Pointers to existing solutions
> > to this problem would be superb.
> >
> >
> > Thanks,
> > Jason
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> > For additional commands, e-mail: users-help@subversion.tigris.org
> >
> >
>
>
> --
> - Jason
>
--
- 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
Posted by jason marshall <jd...@gmail.com>.
On 2/28/07, Bryant Eastham <be...@pewla.us.pewg.panasonic.com> wrote:
> Jason-
>
> I believe that you are confusing the requirements of version control
> with the issues of distribution tracking.
Entirely possible, but I think the fact that the FAQ bears a question
very close to what I'm asking indicates that's not entirely true.
Unfortunately the FAQ answer reads more like an apology than a
rationale for why nobody would want to do that.
> Obviously the problem doesn't exist for people that have access the SVN
> repository - they can just ask and they will know exactly what tag they
> are working with.
Actually, the problem ONLY exists for people that take the code from
the repository. I have a little website where I publish the artifacts
from a Continuous Integration tool. It tags and bags all of the
builds (including the ones determined to be important), and everyone
who uses that site always knows exactly which build of the code
they're running.
It's the people who want to grab the code from the repository (or
can't access the website, for various sad reasons) that can't get the
build artifacts as originally generated. They have to re-generate
them through the build tool (in this case, Ant). But I have no way of
injecting the build number into the build scripts, short of a manual
process. I use the tools I use because they take the human factor out
of things that people are bad at (like bookkeeping), and this throws
the human (me) right back into the fray.
-Jason
> It seems that your issue is getting some level of information to people
> that obtain your source through some other method. If so, I would try to
> solve the problem at the point of creation of the distribution. What
> process do you use at that point? A Makefile with "make dist-src"? Some
> manual process? It seems that is the appropriate place to generate such
> other reports.
>
> For example, I can do a "make dist-clean; make dist-src" in our tree,
> and it will do exactly what I need. Part of that process is creating a
> tagged README, License, and version files. Those files are always static
> in SVN, dynamic in the distribution.
>
> The system is completely automatic, and it works for any src tree
> anywhere (trunk, tag, branch) which has benefits internally as well as
> externally. As it turns out this is the same solution used to get the
> information into our binaries.
>
> Just my .02. If you are interested I can forward the Makefile lines, but
> it is all pretty easy.
>
> --
> 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: Wednesday, February 28, 2007 4:57 PM
> To: users@subversion.tigris.org
> Subject: Putting the tag name in the tagged code
>
> I have a requirement for my code repository that I don't think is
> exotic, or honestly all that uncommon. I need to get accurate version
> information into any binary built from an SVN tag directory, for
> purposes of version tracking and customer support.
>
> I can certainly accomplish this with pre-built binaries. Many
> Continuous Integration tools have facilities for doing this (and
> generating the tags to begin with), but that only helps when I'm doing
> a binary distribution. Is there a way to accomplish the same thing
> (automatically!) with a source distribution?
>
> The general consensus seems to be that it's both unwise and fairly
> brittle to have an on-commit modification (such as code beautifying)
> to the source tree. However, with a tag we're generally NOT expecting
> anyone to update it, and at least in our case it's being created
> directly in the repository, so there is no repos/working directory
> inconsistency to mitigate.
>
>
> So my question is, how best should I accomplish this? A pre-commit
> hook? Groveling around in the svn info data to extract the tag
> directory or revision number information?
>
> Any suggestions would be appreciated. Pointers to existing solutions
> to this problem would be superb.
>
>
> Thanks,
> Jason
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org
>
>
--
- Jason
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org