Ben Collins-Sussman <firstname.lastname@example.org> wrote on 05/29/2004 09:22:47 AM:
> Mark Phippard wrote:
> > By the way, I am wondering if anyone is thinking about or working on a
> > "Subversion Cookbook"?
> Have you seen this? Especially the last section on branching policies?
I hadn't, I will take a look.
I also re-read Chapter 4 last night after I posted the message. It
actually addresses a lot of my concerns a lot better than I had originally
thought. I still think my main concern is that in the scenario I proposed
there will be many "permanent" branches, and over time those branches will
seemingly need to merge changes from different sources. I am sure that
Subversion handles it, I would just love to see it spelled out more.
For example, suppose that the R1.0 maintenance branch and tag are made off
Trunk revision 10. Sometime later, I get a CustomerA that I am going to
do Mods of R1.0 for. Do I copy the tag to create their branch, or do I
have to re-copy Trunk at revision 10. Also, let's assume that the HEAD of
trunk is now at 40 when I do the copy.
I make a bunch of mods for the customer and ship them.
At revision 60 a R2.0 branch is started and at R64 an R2.0 tag is made
when the release is finished.
So, back to my CustomerA mods, how do I catch them up to R2.0? Perhaps by
merging with the R2.0 tag and specifying --ignore-ancestry?
If I used the R2.0 branch as a reference wouldn't it only know about the
changes made between r60:64? Could I use the R2.0 branch and specify
r10:64? I suppose I could since the copy will follow history back before
Just thinking out loud, does the process become more complicated as we
progress to R3.0 and R4.0 or is it just the same basic steps over and over
again? I think it is the latter. Anyway, I will probably try to simulate
it all next week so I can see for myself.
To unsubscribe, e-mail: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat May 29 16:34:02 2004