On Sat, Feb 11, 2006 at 04:40:11PM +0100, Lars Gullik Bjønnes wrote: > Martin Vermeer <[EMAIL PROTECTED]> writes: > > | On Sat, Feb 11, 2006 at 03:21:12PM +0100, Lars Gullik Bjønnes wrote: > | > Martin Vermeer <[EMAIL PROTECTED]> writes: > | > > | > | > I am busy right now but I will hopefully find some time for testing > by > | > | > the end of next week. > | > | > | > | Let's hope the tree is open for 1.4.1 then... > | > > | > But it really should be tested somewhere else... don't you think, a > | > trunk or a branch. > | > | What, itching to try out branches on SVN? ;-) > > I will create my own personal tree under branches/ farily soon, I'd > rather keep my WIP there than on my own disk. > > branches/developers/larsbj > > or something. > > If you have a better suggestion for the /developers/ name then I'd use > that instead. (users, personal etc.)
Why the extra level? If you go this way, /branches/<userid> would be fine, I think. > | What about just putting it into 1.5 after Michael and hopefully someone > | else has tried it at home, and then, when found OK, backporting to > | 1.4.1? > | > | After all, I think we agreed that we needed to do this, that change > | tracking is crippled by the inside-paragraph limitation. > > Sure, but 1.4.1 is not the place to test it. Yes, you're right... The manual recommends the practice of "release branches" and "feature branches". For us, that would mean a branch 1.4 (from which we "tag" the releases 1.4.0, 1.4.1, ...) and a trunk (where we continue developing, and in due time branch off 1.5). The middle of the road approach to feature branches is, to commit smaller patches directly to 1.5, which should always remain compilable and non-broken. Feature branches -- which could bear the name of the feature owner, but more logically that of the feature, e.g. /branches/ct-by-par (or even the bug number), -- should only be used for "large" changes. As the book says: "A good rule of thumb is to ask this question: if the developer worked for days in isolation and then committed the large change all at once (so that /trunk were never destabilized), would it be too large a change to review? If the answer to that question is "yes", then the change should be developed on a feature branch." So that would be my proposal... trunk, after branching off 1.4, in this case. Generally, let's create feature branches only according to need. - Martin
pgpL23IXcXEKb.pgp
Description: PGP signature
