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_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?
>
> 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_at_subversion.tigris.org].
Received on 2009-09-21 07:05:17 CEST