[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Pushing asynchronous changes to production

From: Byron Brummer <byron.brummer_at_livenation.com>
Date: 2007-01-26 01:51:36 CET

Janine Sisk wrote:
> I found a few people asking this question, and could probably have found
> more if I'd known the right keywords to use, but didn't find any really
> satisfying answers.
> We have a fairly typical development/production website setup. Under
> CVS we tagged the files that were ready to go to production with
> "stable", and then (because the production site was created via a
> checkout on the stable tag initially) used cvs update to move them to
> production. This is easily scripted for the less technical user, and
> has worked well for us. Each person can move only their changes without
> knowing or caring if someone else has checkpointed their work by
> committing but is not ready to go live with it yet.

        Except where changes overlap historically in the same file,
        at which point user A may inadvertently push one of user B's changes
        as well.

        But in practice this is often rare and can be made viable enough
        to be a minor issue. Something similar to this is my preferred
        method for this type of environment.

        What you're doing is creating a "mixed revision". Keyword search
        on "mixed revision working copy" should bring up some info on svn's
        ideas of how to do this. It isn't nearly as sane as CVS, but
        something similar does exist in SVN.

> The question is how to emulate this setup in svn. It's not possible to
> tag only the commits you want moved to production anymore, and making a
> branch for every little change is not very practical.


> One person suggested passing a filename and revision number to a script
> that would update the file to that revision, but as far as I can tell
> "svn update" doesn't take filenames, only directories, so I"m not sure
> how to do that.

        svn update does accept filenames actually (maybe you're thinking
        of checkout?). What you'd do is create a mixed revision local
        copy and "tag" (really a copy) it to a tag (prod/tag/build_1234)
        wholesale. There's a ton of issues with svn's tag design, but it
        is there.

        A "moving" tag as you might use in CVS isn't so easy. If you want
        to "move" a tag name you need to delete it first, then copy the
        new set back to it wholesale. PITA.

        Making each a unique tag is a better plan, "build_1234", etc.
        Easier to deal with, easier history, etc. Still not ideal (see
        the last week or so for debates about adding real labels to svn
        to augment it's odd idea of "tags"), but better then nothing.

> I know there are many home-grown solutions to this problem out there,
> and I'd love to hear about them, but it seems there should be a
> recommended way to handle it and I haven't been able to find it, if it
> exists.

        The devs don't grasp this use case, so having it documented is


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Jan 26 01:52:51 2007

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.