Re: Site management strategies with Subversion
Re: Site management strategies with Subversion
- Subject: Re: Site management strategies with Subversion
- From: email@hidden
- Date: Tue, 14 Mar 2006 11:10:48 -0800
I was just looking at the branching/merging chapter of the red-bean
book, and it looks like not even having my own working branch is
going to completely save me, because when you go to merge changes
it's still based on a revision, not on a per-file basis. So I'm
still stuck with having work in progress pulled in along with the
work I'm ready to publish, if that work in progress has been committed.
It's beginning to look like having a repository per framework is
going to be the cleanest way to handle this, but yuck-pfooey! Remind
me again why Subversion is so much better than CVS? :)
thanks,
janine
On Mar 14, 2006, at 10:43 AM, Arturo Perez wrote:
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