FreeLists / openbeos / [openbeos] Re: Organizational question

["Mikael Jansson (mailing lists)" <lists@xxxxxxxxxxxxxxxxx>]

Cian Duffy <myob87@xxxxxxxxx>:
>
> > > Suggestion: Move to Perforce if/when G.E branches off into a 
> > > seperate
> > > tree.
> > 
> > ?
> > Anyway, we would benefit from a better versioning tool instantly, 
> > there
> > is no need to wait *if* the alternative is there and working.
> 
> Oops, I made the assumption a BSD like "split" might happen when R2
> work starts and R1 is "out there" but being stabilised and patched -
> like FreeBSD's 4.x and 5.x trees at the moment. If this isn't going 
> to
> happen, pretend I never mentioned it :-)
> 
Well, that would indeed be what happens.

Correct me if I'm wrong, but this is usually how you do development:

Do work in //depot/main/..., which would represent today's current/ 
directory. Then, when R1 is released, tag all files with the label 
Haiku_R1, and continue working in //depot/main/...

When a bug is squished in the main-line tree that's also in R1, one 
creates a branch from //depot/main/... to //depot/release/r1/..., and 
merge the change from the mainline with r1.

A perhaps more realistical example would be if an experimental tree is 
created:

p4 label, and give it the name label.
p4 integrate //depot/main/... //depot/exp/...

The developers do some changes in exp, and realize they've fixed a bug 
there. Then they can easily do a diff against the main-line and merge 
their changes.

This might actually be what you initially said/asked for, but perhaps 
it would be a good idea to enlighten our readers.

Also, I do agree with Axel that we need a better tool for revision 
handling.  Perforce with its integrated jobs (that connects to other 
bug trackers, such as Mozilla's) could replace in-file TODOs and 
similar constructions. (like I've talked about in a previous mail.)

--
Mikael Jansson
http://mikael.jansson.be