The old problem if you do all development on a single stream, yet want
to release using mix-n-match from historical versions. I can safely say,
you're not using your SCM in any best practise mode.
What I can say, if you want to continue using it like you do is to
Make a tag branch from revision 1200 (the oldest file rev you want in
your release), then merge all other files from 1200 to their desired
revision. This way, you have a baseline at 1200, and you bring each
other file up to the revision you want to release them. An alternative
to this would be to simply copy each file revision to the tag directory
So if you want file.a_at_1200 , and file.b_at_1250, and file.c_at_1500 you can.
Furthermore, you can then make additional changes to those files in
their branch to make them work together (as I wouldn't have thought
taking such an old file and using it with new files will work without
The alternative is to use externals. Create a release directory and set
the externals properties to extract each file from their original
location using the desired revision number. This has the disadvantage
that you cannot then easily modify them - you're picking out revisions
from your historical record. If you do want to make modification, you
will have to branch the file at the old revision, make the change to
that, and then use that in the externals directory.
Most people however, use branches to release, either performing all dev
work on trunk and then branching at release time, or performing all work
on development branches and merging the changes onto the trunk to
release. (and sometimes both, dev work on branches, merge to trunk, then
branch off trunk to create a release).
From: Stephen Connolly [mailto:stephen.alan.connolly_at_gmail.com]
Sent: Monday, September 21, 2009 10:39 AM
Subject: Re: help with a specific revision / patch for release.
2009/9/21 Gavin Baumanis <gavinb_at_thespidernet.com>
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
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:
why not just go with a mixed revision working copy of trunk
svn co svn://___/trunk
svn update -r 1200 somefile.ext
and then create the tag from your working copy
svn cp . svn://___/tags/foobar-1.0 -m "release of foobar-1.0 with
approved changes to somefile.ext"
To unsubscribe from this discussion, e-mail: [users-unsubscribe_at_subversion.tigris.org].
Received on 2009-09-21 12:29:56 CEST