Molle Bestefich wrote:
> One of the reasons being that since it's entirely (easily?) possible
> to implement a keyword which reflects 'working copy last commit' in
> Subversion, it's dumb that every developer or admin or whatever around
> the world has to waste his time implementing his own inferior solution
> in his own build scripts (or what not).
It's not possible in the current system to create such a keyword and I'm
still going to argue that it wouldn't be that useful (except possibly
for a very small subset of projects) even it it was possible.
Let me try and explain this another way. Keywords are applied to
*files* and they reflect some attribute of that specific file. When you
are using the $Revision$ keyword in a file, you are getting the
repository Rev in which *that file* was last updated. The only time
that any keywords are updated in a file is if it is "dirty" which means
either updated from the server or changed locally and committed.
Now, a directory can also have a Rev associated with it, which is the
last time that update was run in that directory. When you type 'svn up'
you are updating the directory (and everything below it unless you do
non-recursive) to the current Rev in the repository for all of those
files. But there is no way to expose that information, because the
directory doesn't have a "file" that you can add $Revision$ to in order
to expose that information.
What svnversion does is to display:
1) The Rev for the last time the *directory* was last updated;
2) If any object(s) (file or directory) contained in that directory have
been updated to a higher Rev, it also displays the highest applicable value.
There is no way currently to mark a certain file as "dirty" so that it
always has its keywords rewritten for every update, so the technique
which has worked for most people is to use svnversion (or SvnWCRev) to
extract the 'working copy last commit' and store it in a file outside of
Subversion's direct control. This is something that only needs to be
done once for any given build tool, so it isn't really a chore.
> Yes, it is immensely useful for communication purposes.. We
> communicate revision numbers between developers on a daily basis..
Yes, internal development is the one place where this works.
> But it's also useful to stuff it in end user software.
Except that is is trivially easy for this information to be wrong or at
the very least misleading. I'm a developer of your product and I'm
trying to get a release out for Mr. Big (your best customer). I
discover a late bug and rather than fixing it the right way, I revert a
file to an earlier working version and cut a release. Later on, Mr. Big
calls in with a problem and someone else cannot reproduce the problem
because the "version" listed in the Services panel doesn't even compile.
If, instead, your description field contained the tag that the
application was built off of, you would always be able to recreate any
release.
>> 1) Branch for the release, complete testing and any integration to the
>> branch until ready to release.
>>
>> 2) Tag the branch and release off the tag, using a tag name which
>> corresponds to the externally visible package name.
>
> That's highly impractical for small projects or projects that are
> released often.
I strongly disagree. Even if you don't have a firm testing scheme (and
you should), you can easily skip step 1 and just tag/switch/release.
You don't even /need/ to do the switch, as long as your release process
captures what tag you are setting in the source code some way. It could
be automated or it could be manual. Copies are cheap and even if you
have hundreds of custom releases, you can organize your repository to
have project/tag/customer/release/... so that you don't go quickly mad.
Or just tag based on your initials and the date (so it's easy to find
out who to beat up for mistakes). ;-)
HTH
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Boulevard
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5748
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 29 20:46:39 2005