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].
Received on 2009-09-15 06:41:36 CEST