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.lii...@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...@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...@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-unsubscr...@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.
