You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Gavin Baumanis <ga...@thespidernet.com> on 2009/09/21 01:33:03 UTC
help with a specific revision / patch for release.
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;
/trunk/myFile.a
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@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.
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397177
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
RE: help with a specific revision / patch for release.
Posted by "Bolstridge, Andrew" <an...@intergraph.com>.
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
either:
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
individually.
So if you want file.a@1200 , and file.b@1250, and file.c@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
some modification).
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).
Andy
From: Stephen Connolly [mailto:stephen.alan.connolly@gmail.com]
Sent: Monday, September 21, 2009 10:39 AM
To: users@subversion.tigris.org
Subject: Re: help with a specific revision / patch for release.
2009/9/21 Gavin Baumanis <ga...@thespidernet.com>
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;
/trunk/myFile.a
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@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.
Gavin.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageI
d=2397177
To unsubscribe from this discussion, e-mail:
[users-unsubscribe@subversion.tigris.org].
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"
-Stephen
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397268
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: help with a specific revision / patch for release.
Posted by Stephen Connolly <st...@gmail.com>.
2009/9/21 Gavin Baumanis <ga...@thespidernet.com>
> 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;
> /trunk/myFile.a
>
> 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@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.
> Gavin.
>
> ------------------------------------------------------
>
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397177
>
> To unsubscribe from this discussion, e-mail: [
> users-unsubscribe@subversion.tigris.org].
>
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"
-Stephen
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397251
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: help with a specific revision / patch for release.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 21, 2009, at 00:04, Gavin 'Beau' Baumanis wrote:
> I have used;
> svn merge -c 1200 ...
> and it didn't seem to work.
> I got a lot of conflicts.
> I can't think of the exact use-case.... perhaps it was something odd
> like trying to a merge a specific change from customer1 to customer2
> that caused the issue... - I really can't remember....
> But needless to say it turned out to be a really painful and manual
> exercise... so much so that I have pretty much only ever merged a
> file that was at head to the production branch.
It all depends on what changes have happened since then. For example,
if you are trying to merge changeset 1200 from trunk into the branch
now, but other changes have been made to those files in the branch
since then, then changeset 1200 might not apply cleanly anymore. Or if
you're trying to merge changeset 1200 from trunk into the branch, but
that changeset depended on prior changes on trunk that you haven't
merged yet, then you'll get conflicts. When conflicts occur, you must
resolve them manually. Hopefully by looking at the diffs of the
conflict files Subversion produces, you'll be able to see what edits
you need to make, or perhaps learn that you need to undo that merge
and first merge some earlier revisions.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397203
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: help with a specific revision / patch for release.
Posted by Stein Somers <ss...@opnet.com>.
Gavin Baumanis wrote:
> As for the merge... we always use;
> svn merge -c xxx or
> svn merge -r n-1:nx and it seems to work fine.
>
> Previously, I have used;
> svn merge -c 1200 ...
> and it didn't seem to work.
I don't see the difference, apart from "...", but you need to specify at
least a source anyway.
Beware that when you merge -c 1200 or -r 1199:1200, you only merge the
changes applied in that changeset. If you want to synchronize to the state of
revision 1200, you need to merge up to 1200.
--
Stein
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397282
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: help with a specific revision / patch for release.
Posted by Gavin Baumanis <ga...@thespidernet.com>.
Hi Ryan,
We do have a release branch.... but it is not 'tagged' everytime we
update the production code.
The production branch is a complete copy of what's live in a
customer's site right now.
So we don't have a discreet copy, of changes that got released to
production last xxxx (week / month etc).
I'm not sure that's really such a problem... but mentioned it just in
case... someone had a strong feeling against doing it this way.
I'm always open for doing things in a better / more efficient way.
As for the merge... we always use;
svn merge -c xxx or
svn merge -r n-1:nx and it seems to work fine.
Previously, ("I" would say I am certain about what I am going to say
next, but of course - could be completely wrong -and thus pretty much
the point of the thread)
I have used;
svn merge -c 1200 ...
and it didn't seem to work.
I got a lot of conflicts.
I can't think of the exact use-case.... perhaps it was something odd
like trying to a merge a specific change from customer1 to customer2
that caused the issue... - I really can't remember....
But needless to say it turned out to be a really painful and manual
exercise... so much so that I have pretty much only ever merged a file
that was at head to the production branch.
Eg.
I have edited a file and now (after that edit/commit) the repo is now
at 1300... then I use,
svn merge -c 1300 /trunk/.... /branches/production/...
or
svn merge -r 1297:1300 .....
As a practice.. I always use the "latest" revision of a file when
performing the merge operation.
Because of the previous history of "awkwardness" I pretty much put it
down to me doing something wrong or SVN simply not working they way I
was expecting it to - and basically have never since tried to do a
merge of a change-set where the code is not at the HEAD revision....
Though thinking about it (now while typing) ... technically it doesn't
even make sense to me that it should work at head at not any other
change-set...
I think it is simply case of give it another go and see if anything
specific comes up, and get help on that - if needed.
I'm kinda sorry I've wasted everyone's time... but by writing the
mails it seems therapeutic towards fixing the issue i "thought" I was
having.
Gavin.
On 21/09/2009, at 14:42 , Ryan Schmidt wrote:
> On Sep 20, 2009, at 20:33, Gavin Baumanis wrote:
>
>> I have a file;
>> /trunk/myFile.a
>>
>> 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@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?
>
> So, do or don't you have a tag per release?
>
> I think you probably just need to "svn merge -c1200" from the trunk
> into your release branch. Then, if you use them, you can make a new
> tag from the release branch.
>
> How do you normally get changes from your trunk into your release
> branch, if not by merging? Merging would be the usual way to do this.
>
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397202
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].
Re: help with a specific revision / patch for release.
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Sep 20, 2009, at 20:33, Gavin Baumanis wrote:
> I have a file;
> /trunk/myFile.a
>
> 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@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?
So, do or don't you have a tag per release?
I think you probably just need to "svn merge -c1200" from the trunk
into your release branch. Then, if you use them, you can make a new
tag from the release branch.
How do you normally get changes from your trunk into your release
branch, if not by merging? Merging would be the usual way to do this.
------------------------------------------------------
http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2397197
To unsubscribe from this discussion, e-mail: [users-unsubscribe@subversion.tigris.org].