Re: Merging / reintegration procedure

[iguy <ir...@gmail.com>]

Rob,

I realize that this is an old thread, but just in case you remember it...

In your scheme, where do bug fixes found during testing take place?

Ira

Rob van Oostrum-2 wrote:
> 
> Please keep replies on the list.
> Yeah that's one drawback, but that's what svnmucc was invented for:
> http://svn.collab.net/viewvc/svn/trunk/tools/client-side/svnmucc/svnmucc.c?revision=35894&view=markup
> 
> It lets you group both commands into one revision.
> 
> Re. continuous integration, I would have those builds create a tag upon
> successful completion, so my complete high-level tree would look like
> this:
> 
> /trunk
> /branches -> projects, features, etc.
> /tags -> developer tags
> /environments -> staging, production, etc.
> /builds
>     /development
>         /build.1
>         /build.2
>         etc, etc, etc.
>     /staging
>     /production
> 
> So my CI tool (CruiseControl, Hudson, Bamboo, etc.) will create tags under
> /builds, with /builds/development being the builds from /trunk for
> example.
> So rather than a developer telling me to promote trunk to staging, where
> another developer might be sneaking in changes in the meantime that
> shouldn't go out yet and/or might break the build, I ask for the build to
> promote (because that's the only way you know the build should actually
> pass, otherwise you might get half the changes committed between two
> builds). So I copy /builds/development/build.100 to /environments/staging.
> This hopefully results in a successful build/deployment, and I will now
> have
> a build tag e.g. /builds/staging/build.10
> 
> When QA and the client approve, that build tag is promoted to
> /environments/production, which results in e.g. a
> /builds/production/build.2
> tag.
> 
> So now I can instantly pull up a) the current state of each of my
> environments, b) the past states of each of my environments and c) what
> was
> or was not included in each of the builds that live in each of my
> environments.
> 
> If I run 'svn log' on /environments/production, I see it was copied there
> from /builds/staging/build.10, which in turn was copied from
> /environments/staging, which was copied from
> /builds/development/build.100,
> which was copied from /trunk. Anything that was committed to /trunk past
> the
> revision that was copied to staging doesn't show up, and is therefor not
> in
> production.
> 
> May not work for everyone, but it always has for me.
> 
> 
> Hope it helps,
> 
> Rob
> 
> On Mon, Sep 14, 2009 at 11:11 PM, Alex <al...@gmail.com> wrote:
> 
>> Thanks Rob.  That sounds like an interesting approach, and basically
>> what I want most of the time, although I don't entirely understand how
>> you do it.  I also don't like all the merging I have to do.
>>
>> A tag is created using "svn cp" I think, so this is the only way I see
>> to do it, for promoting to production for instance, is:
>>
>> svn rm environment/production
>> svn cp branches/staging environment/production
>>
>> Which means I need to do two commits every time.  I was doing this for
>> a while but it was ugly.
>>
>> I don't know what "continuous integration build tag" means.  Is that a
>> feature of subversion?
>>
>> Thanks.
>>
>> On Sep 14, 2:31 pm, Rob van Oostrum <rv...@gmail.com> wrote:
>> > Alex,
>> > What I like to do is the following:
>> >
>> > - Rather than keep branches corresponding to my environments, I like to
>> use
>> > tags.
>> > - For each release/promotion of a build to staging/production/etc, I
>> > recreate that environment's tag. In the development -> staging ->
>> production
>> > scenario, I typically use a continuous integration build tag for
>> > development, copy it to the staging tag, and copy the staging tag to
>> the
>> > production tag.
>> >
>> > There are variations on this basic theme that I sometimes use. Since my
>> > builds are all automated anyway, I usually just reuse the same
>> continuous
>> > integration tool from development for all my other builds. So every
>> build
>> > that's run on e.g. staging gets its own build tag. In cases where
>> > internal/external clients are exposed to these build numbers, I'll
>> sometimes
>> > be asked to e.g. "promote staging build 123 to production". In that
>> case
>> > I'll just copy that build tag to the production tag (so I don't have to
>> > worry about whether build 123 was the latest build or not).
>> >
>> > What I like about this approach is that it gives me traceability on
>> what
>> was
>> > promoted to production when, and when it went through what stages of
>> > testing/verification. And by running 'svn log' on the tags' parent
>> folder
>> (I
>> > like to use a trunk/branches/tags/environments set of top-level
>> folders),
>> > wrapped by a little bit of clever scripting, I can quickly dig up
>> exactly
>> > when each environment was deployed to and from where.
>> >
>> > Regardless of whether this is useful to you, I would never, ever use
>> merging
>> > as a means of triggering a build/deployment. Too much room for human
>> error,
>> > and way too little room for automation/remote triggering (I like
>> triggering
>> > builds by manipulating these tags through SSH macros from a
>> > Blackberry/iPhone).
>> >
>> > Hope this helps,
>> >
>> > Rob
>> >
>> >
>> >
>> > On Mon, Sep 14, 2009 at 3:17 PM, Alex <al...@gmail.com> wrote:
>> > > Here is my branch structure
>> > > - trunk
>> > > - branches/staging
>> > > - branches/production
>> >
>> > > We do you primary development on trunk, and do bug fixes on staging.
>> > > When trunk is ready and stable, I want to merge all of those to
>> > > staging.  Our deployment system (beanstalkapp.com) always deploys
>> from
>> > > branches/staging.
>> >
>> > > I have three choices:
>> > > 1) Merge changes from trunk into branches/staging.  I have tried in
>> > > branches/staging:
>> >
>> > > svn merge  --reintegratehttp://[url]/trunk ./ --accept theirs-full
>> >
>> > > but this leaves diffs when I go the root and do:
>> >
>> > >  diff -r trunk/ branches/staging --exclude=.svn
>> >
>> > > 2) Move branches/staging to branches/staging-[date/version] .  Then
>> > > copy trunk to branches/staging.
>> >
>> > > 3) Copy trunk go branches/staging-[date/version], then update our
>> > > deployment system to deploy from the new branch.
>> >
>> > > I have been doing (2), but I don't really like it.  (1) seems to
>> > > better keep track of revisions, but I'm willing to accept that might
>> > > be wrong.
>> >
>> > > Ideally subversion would support some type of "symbolic link".  I
>> > > could have branches/staging-v1.3 and branches/staging could be a
>> > > symbolic link there.  This would allow the deployment system to not
>> > > need to be updated every time.
>> >
>> > > Any thoughts?
>> >
>> > > Thanks.
>> >
>> > > ------------------------------------------------------
>> >
>> > >http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessa.
>> ..
>> >
>> > > To unsubscribe from this discussion, e-mail: [
>> > > users-unsubscr...@subversion.tigris.org].
>> >
>> > --
>> > Polarion Software
>> >
>> > Subversion Training & Consulting Services |
>> www.polarion.com/services/index.php
>> >
>> > Download Eclipse bundled with Subversive today! |
>> www.polarion.com/products/eclipse/
>> >
>> > ------------------------------------------------------
>> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessa...
>> >
>> > To unsubscribe from this discussion, e-mail: [
>> users-unsubscr...@subversion.tigris.org].
> 
> 
> 
> 
> -- 
> Polarion Software
> 
> Subversion Training & Consulting Services |
> www.polarion.com/services/index.php
> 
> Download Eclipse bundled with Subversive today! |
> www.polarion.com/products/eclipse/
> 
> ------------------------------------------------------
> http://subversion.tigris.org/ds/viewMessage.do?dsForumId=1065&dsMessageId=2394864
> 
> To unsubscribe from this discussion, e-mail:
> [users-unsubscribe@subversion.tigris.org].
> 

-- 
View this message in context: http://old.nabble.com/Merging---reintegration-procedure-tp25441890p28964215.html
Sent from the Subversion Users mailing list archive at Nabble.com.

Re: Merging / reintegration procedure

[Rob van Oostrum <rv...@gmail.com>]

On Tue, Jun 22, 2010 at 3:47 PM, iguy <ir...@gmail.com> wrote:

>
> Rob,
>
> I realize that this is an old thread, but just in case you remember it...
>
> In your scheme, where do bug fixes found during testing take place?
>
> Ira


Depends.

For example, take this scenario:

QA finds a bug in QA build #10, you have this chain (through the 'copied
from' paths/revisions you get with svn copy):

^/builds/qa/10  <-- tag created by CI server upon successful
build/deployment to QA
^/environments/qa@99 <-- tag created by the build manager to trigger the
build/deployment to QA
^/builds/dev/999 <-- tag created by CI server
^/trunk@12345

So now you have a bunch of option as to where to fix the problem, based on
whatever your preference/process is, or sometimes the circumstances force
you down one path or another, and this approach gives you the tools to do so
elegantly, for example:

a) fix in trunk (where the other changes going into the build are)
b) create a branch from ^/trunk@12345 (to exclude anything on ^/trunk since
r12345), fix on branch. This is identical to a release branch approach. You
reuse the same branch for any subsequent fixes/changes related to getting
that build passed, without affecting the overall scope.
c) create a branch from wherever the problem was first reported, in this
example ^/builds/qa/10, so I don't have to think/trace where anything
originated. QA says "build 10 is broken", DEV says "we need a branch to fix
the thing that broke QA build 10", and I say "I'll give you a branch based
on QA build 10". This is makes it easier to automate e.g. for (web-based)
self-service. Potential downside is that you may end up having a bunch of
different branches containing partial fixes for something that took multiple
builds to finally resolve. But in a QA-driven process, sometimes having that
kind of traceability outweighs keeping related changes in one place.
Probably not something I would recommend as a matter of routine.

Hope that helps / gives you an idea

Cheers,
Rob