On 10.11.2010 18:04, Richard M Willis wrote:
> I need to get my build process automated so that the subversion
> revision number is somehow compiled into my deliverables. I need it
> to either give a revision number or "no number at all" if either the
> WC is mixed-revision or has local modifcations. This I can do with
> However, I also want to include this process to get the "release
> number" and use that in place of or in addition to the above number
> if it has one
> The definition of "has a release number" is that the WC should have
> been checked out from a URL ending branches/releases/x_y_z. This I
> can do also with SubWCRev as that delivers the URL. However, the
> release/x_y_z branch won't naturally have "just one" revision in it.
> I will eventually prevent people committing more than one revision to
> a given release sub branch with a PostCommit hook. Until then,
> however, I want to be able to tell programmatically that the
> checked-out revision comes from the *first* commit to that branch;
> all subsequent ones I want to treat as if they had no particular
> release number ?
> How to do this ? Can it be done without contacting the server ?
No, you would have to contact the server.
But you should consider changing your workflow a little bit. Instead of
making a release branch and define the first revision of that branch as
the release, create a tag of that revision. Then you can filter the url
for /tags/ and use that to determine whether this is a release or not.
If you like, you could then add a hook script which prevents commits to
those folders in /tags/ and you'll be fine.
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest Interface to (Sub)Version Control
/_/ \_\ http://tortoisesvn.net
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_tortoisesvn.tigris.org].
Received on 2010-11-11 18:58:19 CET