Re: Site management strategies with Subversion
Re: Site management strategies with Subversion
- Subject: Re: Site management strategies with Subversion
- From: Arturo Perez <email@hidden>
- Date: Tue, 14 Mar 2006 13:43:07 -0500
email@hidden wrote:
Mind you, I'm no subversion expert (don't even play one on TV :-). I am
learning it as part of my current position. I've been using it for
several months now over several releases. Like you, I prefer Perforce
but we don't always get to choose :-)
This link may help: http://svnbook.red-bean.com/en/1.1/apa.html
On Mar 14, 2006, at 9:53 AM, Arturo Perez wrote:
So what you really need is a way to pick and choose the revisions
that go into your stable copy, not the individual files.
You may be right. Let me tell you how I envision this, and you can
tell me if I'm wrong (please!).
Let's say I check in some changes to frameworkA, which is part of some
ongoing work. This is revision 50. Then I check in some changes to
frameworkB, which is just a small tweak and needs to get pushed to the
live site right away. This is revision 51.
Now, if I push revision 51 to the live site, don't I get the current
state of all files, which includes the stuff I checked in at revision
50 and don't want to push yet?
If you just checkout the current trunk/branch, then yes.
If you need to do this sort of thing then you'll need to use branches as
described here: http://svnbook.red-bean.com/en/1.1/ch04s03.html.
Something like, when production is good, make a tag/cheapcopy of it
called "tags/currentProduction." Then you'll know what to apply your
merges to. Here we run into a failing of the current version of
Subversion. It doesn't track merges (hopefully that's on the TODO
somewhere) so you'll have to keep track of what you merged yourself.
You are correct that what I want in this case is the delta that
revision 51 represents, though that is not always true; I don't
always commit an entire change once, and only once. One file might
get checked in several times by itself, after the first commit that
has them all.
Yeah, I did that too until I figured out what svn was doing. You'll be
much better served by making all of the changes to all of the files for
a feature (a single feature, mind, not a bunch) and then committing them
all together. Alternatively, you can make yourself a private branch and
then merge to the main branch when you're happy. I don't do the latter
with svn because I have Eclipse set to save the last few thousands of
the changes I've made to files.
It may be that in order to work with Subversion I'm going to have to
stop checking in work in progress, but that is sort of a shame. I
have, on occasion, messed things up so thoroughly that I've had to
recover a few files from CVS so I could back out the disastrous change.
thanks,
janine
I use eclipse to save me from that one. If you're not using that then a
branch is what you need. I used to work with some people where the
process was everyone had their own branch.
-arturo
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden