On Apr 2, 2008, at 09:27, uprooter wrote:
> SubWCRev can not help.
> If you take a look at the beginning of this thread you'll see that
> any kind
> of "client side" solution is not good for me,
> One reason is multiple development environments for the same project.
> Another reason is that due to the nature of the final product the
> developers
> find them self occasionally programming in a virtual machines,
> fixing some
> bugs and then commit from theer. so setting up a sane build script
> is not an
> option. not at all.
> I really want the server to do the work, either by committing without
> bumping the revision or by direct file access to the pseudo
> "version.h"
> file.
> Generally , any sever side solution that does not commit would help.
If you want to store a file in the repository which contains the
current revision, and you want the server to do so, then you're going
to be writing a post-commit script on the server which itself does
another commit, which will increase the repository revision. That's
all there is to it. This is not ideal, and it's not a good idea in
the first place, but if you insist on it, then that's how it is.
> I'm thinking of a solution. I'll share it with you if I get to
> something
> usable.
The solution is to use svnversion (or perhaps SubWCRev; I'm not
familiar with it) on the working copy on the client, at the time when
you need to know the working copy's revision number(s). Surely you
already have a build script on each type of client that you support.
You should be able to integrate calling svnversion / SubWCRev into
that build script where necessary.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-04-03 12:44:12 CEST