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.
Yep.
> 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
unlikely.
-Byron
---------------------------------------------------------------------
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