Ok, I think I've got it. I don't like it, but I've got it.
- set up main codebase in /trunk
- create three branches: release, work, tweaks
- set up live site from release branch
- do longer term work in work branch, committing as desired
- do changes that need to go out right away to tweaks branch. Merge
these into the trunk and then into the work and release branches,
update live site
- when longer term project is ready to go, merge it from work branch
into trunk and tweaks and release branches, update live site
I think that will work, but man-oh-man what a pain in the behind!
And of course it only gets worse if you have multiple projects going
on per site - branches every which way!
janine
On Mar 14, 2006, at 11:10 AM, [EMAIL PROTECTED] wrote:
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 PROTECTED] 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 (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/womail%40mac.com
This email sent to [EMAIL PROTECTED]
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webobjects-dev mailing list (Webobjects-dev@lists.apple.com)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com
This email sent to archive@mail-archive.com
