Version references in documentation

Derek Atkins warlord at MIT.EDU
Fri Aug 27 11:02:41 EDT 2010

Yawar Amin <yawar.amin at> writes:

> On 2010-08-26, at 14:01, Derek Atkins wrote:
>> [...]
>> I'm not sure why it scares you; branching in SVN is simple.
> Yes, but....
>> [...]
>> Sort of..  We branch the 2.2 for 2.2 maint; trunk is matching
>> gnucash-trunk.  When we're ready to fork the 2.4 vs. "next major
>> version" then we can branch the docs to 2.4.  But there's no point in
>> branching until you have something that will cause a diversion.
> OK, but, what about non-version-specific work? Like, a typo that
> should be fixed in both trunk and 2.2--or the text width suggestion
> patch I just sent? I would think we couldn't put it in either branch,
> because it affects both. For these cases, could we create a `general'
> branch starting at r11620 (release 1.8.0) where we can make these
> general administrative changes (and general changes only) and neatly
> merge them into all future branches?

Nope, just take the changeset and apply it to all active branches at the
same time.  You can do this in multiple ways:

1) You can just apply it to all branches at once
2) You can apply it to trunk and then "backport" the changeset to the
   other active branches.
3) You can have a "feature" branch that includes the changes and then
   merge that branch into all the active branches.

> I imagine this would involve doing something like:
> for each branch in (1.8, 2.0, 2.2, lentity, trunk)
>   svn merge general-branch into branch
> Would that work?

Yes, that's option #3.  But it's much more work.  #1 or #2 is much easier.

> Also, SVN merging is why I'm so scared of SVN branching. :-)
> Regards,
> Yawar


       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL:    PP-ASEL-IA     N1NWH
       warlord at MIT.EDU                        PGP key available

More information about the gnucash-devel mailing list