Re: Site management strategies with Subversion
Re: Site management strategies with Subversion
- Subject: Re: Site management strategies with Subversion
- From: Lachlan Deck <email@hidden>
- Date: Wed, 15 Mar 2006 07:33:20 +1100
Hi there,
On 15/03/2006, at 6:34 AM, email@hidden wrote:
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!
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?
I'm not sure I'm understanding why your frameworkA and frameworkB
aren't in their own respective svn repository. That way they have
their own version numbers and, of course, your application(s) can
depend on certain versions of them...
with regards,
--
Lachlan Deck
_______________________________________________
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