Re: Site management strategies with Subversion
Re: Site management strategies with Subversion
- Subject: Re: Site management strategies with Subversion
- From: "Geoff Hopson" <email@hidden>
- Date: Tue, 14 Mar 2006 20:13:29 +0000
Remind us again....why do you want to leave CVS? :-)
On 14/03/06, email@hidden <
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!
janine
On Mar 14, 2006, at 11:10 AM,
email@hidden 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@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.
_______________________________________________
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