On Saturday 06 September 2003 19:15, Jack Repenning wrote:
> At 4:13 PM +0100 9/5/03, Peter Childs wrote:
> >On Fri, 5 Sep 2003 e.huelsmann@gmx.net wrote:
> >> you might use the svnversion command to do this:
> >>
> >> compile using gcc -DVERSION=`svnversion .`
> >>
> >> There currently is no keyword which is substituted with the output from
> >> svnversion.
> >
> > Super a keyword might be useful one day however.... maybe a TODO
> >is in order.
>
> Certainly, this idea is getting common enough to deserve a FAQ entry
> (with e.huelsmann's workaround, very likely).
>
> It seems to me (to many of us) that treating this info as a keyword
> creates more problems than it solves. I wonder, if you don't mind,
> if you could explain a bit more of why you want this, and why you're
> not concerned about the problems it engenders?
One of the main gains of Subversion over CVS is that it stores the repository
as a whole not just as changes of individual files. This means SVN has
abilities that many version control management systems do not have. Probably
the main reason we are thinking of transferring from CVS :)
Once you have checked out the repository you need to know what version have a
got. In our case of programming with it we would like to put the revision
number into the executable which is compiled from all the files in the
repository but because its generated it is not stored in the repository.
Then when someone reports a bug they can tell us the version number and we
can rewind the subversion (or recheck it out) with that revision and find the
bug therefore being a to check its existence and b to check if its been fixed
in a later version.
By using subversions revision numbers this can be done automatically without
us having to remember to update a file everytime we commit.
I can see the technical difficulties but I think the advantages out way the
difficulties (personally).
>
> Here's a partial list of those problems:
> * any file containing this keyword would have to be changed (by SVN)
> every time you update, even if the file itself had not changed.
Point taken. Our subversion is slow enough already.
> * The indication is ambiguous, since a given revision number actually
> applies to many complete project versions, in trunk/, tags/*/, and
> branches/*/.
Should not make any difference its no worse that using a date like samba do.
> * Updates of anything other than the whole working copy/build tree at
> once make this very weird--if you update some subdirectory that does
> *not* contain this file, ought this file also to be updated?
Intresting point. That does seam like a major problem.
> * And commits present that same problem in an even worse way, since
> committing a change by definition advances the repository revision,
> and yet does not give you the changes to all the files you're not
> committing.
Which is actually an announce that I've noticed so far. I usually end up
doing a update commit update sequence to get things in. maybe resolving
conflicts if necessary. (Fortinally we only have a development team of 3
currently)
I hope that helps.
Peter Childs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sun Sep 7 09:58:47 2003