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 <alex.liivid_at_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 <rva..._at_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 <alex.lii..._at_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..._at_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..._at_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_at_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.
Received on 2010-06-22 21:47:57 CEST