John Peacock wrote:
> Molle Bestefich wrote:
> > However, we don't use Makefiles.
> > We use VS.Net's build system, in which it is not practical to do
> > something like the above.
> > I imagine the same is true for other build systems..
>
> I'm sure that there is a way to create a build step, even in as
> primitive a tool as VS.Net ;-), that runs some script prior to compiling
> a given file.
There is, and I think I've given plenty of reason why that doesn't
work too well.
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).
> But the piece you are missing is that Subversion _only_ updates keywords
> on files that have *changed*,
That's not a piece I am missing.
That's just behaviour that changes with my proposal :-).
> plus see issue:
> http://subversion.tigris.org/issues/show_bug.cgi?id=1975
> for a situation where Subversion *doesn't* update keywords when it should.
Thanks for the pointer!
Seems that the same change in behaviour just mentioned is needed to
fix this bug as well. Might as well swat two flies in one coding
session.
I've just read the thread you point to in that issue, seems like I'm
not the first to request this feature.
And here I though I was original.. (of course I'm "a original", but
that's different.)
> You are also papering over the situation where your WC is in a mixed
> revision state, which is true anytime you checkin and don't immediately
> update. SubWCRev gets around this by finding the highest rev in the WC
> and returning that.
Both SubWCRev and svnversion can return min:max as an indication of
approx. which state your WC is in. I find that it is sufficient for
my purposes, in the odd case that you do have a mixed revision working
copy, to know the range in which to look. If you need *precise*
$WorkingCopyRevision$, don't use mixed revision WC's. They're a mess,
anyway :-).
> But that still may not accurately reflect the
> actual state of the WC. It is entirely possible to backrev a portion of
> the build tree, say a sub-library which has to be kept stable for
> releases even though further development has occurred in that section of
> the code.
Surely you'll just switch the sub-library to an appropriate tag??
> My primary beef with this whole thread is that Revision is a bookkeeping
> value that arises out of internal implementation of the repository
> architecture and should not be elevated to any greater significance
> (i.e. something like a version number).
That train has left the station a long time ago.
If you don't want people to use revision numbers as version numbers,
you should propose entirely removing the $Revision$ keyword, nuking
SubWCRev off the face of the earth, and probably the same with
svnversion.
(Speaking of which, I do hope that a clean keyword-based solution
could eliminate 95% of the need for both of those tools so that
hopefully we CAN get rid of them..)
> Revision is moderately useful to developers in the actual act of
> developing software under *certain* circumstances,
Yes, it is immensely useful for communication purposes.. We
communicate revision numbers between developers on a daily basis..
But it's also useful to stuff it in end user software.
The Windows services we develop, for instance, have their version
number in the 'Description' field. Whenever we're accessing a
customer system, or a customer calls with a problem, we just (ask
them) to go into the Control Panel, into the Services MMC and look in
the description field, and we instantly know what version they're
running.
For another example, see the TSVN 'about' dialog and go visit the TSVN
mailing list and choke on how many times a day *that* piece of
revision number is being spoken out loud :-).
> but because it is a single value that is global to the
> repository, there are plenty of situations where the value of "Revision"
> does not have any way to capture the complexities of a deliberately
> mixed revision WC.
I don't see your point.
It's not like we're using the repository's HEAD revision. We're only
using what's relevant, namely the 'last commit' revisions of the files
in the WC we're interested in.
As for mixed revisions, I've commented on that further above and below.
> If you want to ensure that you can find the corresponding set of files
> for a given release, use the same methodology as Subversion employs:
>
> 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.
> Only by creating a tag, which will encapsulate mixed revision
> development, can you be guaranteed to be able to go back later and
> recreate a given set of files accurately.
We don't use mixed revision development.
The SVN CLI doesn't do a good job with mixed revision WCs (IMHO), and
we've managed to find better solutions any time we've encountered
something which mixed revision WCs would solve.
It's obvious if you deliberately update all files in your WC to
different versions, that a $WorkingCopyRevision$ keyword will be
mostly useless to you.
Hmm. Have I proposed that this feature targets people who deliberately
mix their WC's? It does not. They can use $Revision$ instead.
I'm not exactly sure where you're going with this...
Madan U Sreenivasan wrote:
> So, what isnt svnversion available in windows?!
Sure is.
Both svnversion and SubWCRev are abominations (excuse me :-)) meant to
do what is much more elegantly done using keywords, as far as I can
see (feel free to enhance my vision). But I'm after the elegant,
no-hazzles solution here. I'm *not* trying to prove that it *cannot*
be done with an inane amount of mucking about with current tools.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Sep 29 19:41:58 2005