[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

help with a specific revision / patch for release.

From: Gavin Baumanis <gavinb_at_thespidernet.com>
Date: Mon, 21 Sep 2009 11:33:03 +1000

Hi Everyone,

This is one of those silly questions... you know the kind... where you
probably should just know the answer - but don't.

So in the vain of; "There is no such thing as a silly question" here
it is.

I have a file;

It is currently undergoing significant development.
One of those developments has been approved for release.
Normally, we only do a small change or so per file and then create a
new tag for release from HEAD.

The sticking point for me is;
The change that is approved - is at r1200. The repo currently sits at
r1500 - with a significant number of changes made to File.a in between
1200 and HEAD.
(Which is the bit that is odd for me - in that I have never dealt with
that scenario before.)

I could make a release tag_at_1200
But then that locks all files to be of no greater a revision that 1200.

I suppose I could simply do a diff of 1200:1199 for /trunk/File.a and
obtain a unidiff.
Make a copy of the current release tag. - Which is another problem -
because we actually don't have a tag per release we just have a
forever ongoing branch that we use for production uploads.
And apply the new patch - then commit the new release tag?
Which seems reasonable enough to me... - but that isn't necessarily
saying a lot!

And while I realise there could be any number of ways to deal with the
scenario... is there a generally accepted one? - Along the lines of -
just about everyone uses trunk / branches and tags a being the
"accepted" general layout for a repository?

I'd rather not get into a bad habit - if there was indeed a "better"
way to do it.

As always - Thanks for all your help.


To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-21 03:33:55 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.