thoughts about branches

[Henning Sprang]

Hi,

When starting to create the patch for fai-cd, and therefore got started
with creating my people branches directory, some thoughts about
branching and merging in subversion came over me - some could become
additions to the fai subversion howto, (I'd add them there as soon as we
have some consent), some are just concerns or ideas how to solve those
concerns:

- if you want to make a patch against a bug in a specific release,
create a personal branch from the release tag, not from trunk (e.g. we
don't want to add the the fai-cd patch, which we want to get into the
next sarge update, to the current development head in trunk).
(do we need to explain the naming scheme and how to find a tag for a
given release? generally you'll have to look for
r-<RELEASE-VERSION-WITH-DOTS-CONVERTED-TO-UNDERSCORES> in the /tags
directory.

- if we need multiple small patches like that, they still get made that
way, but thomas creates a branch from the target release tag, merges the
multiple changes in there, and creates a new release tag from that
branch. we should think about a naming convention for those branches.

- we need to keep book about which patch (say, changes in which branch)
we already merged into which other branch, when. When working with CVS
in my last job, we also marked those merges with a tag. in subversion
this is probably not necessary, because such an operation will have a
unique revision number over the whole repository, but how do we
mark/document them, and how can we extract that information when we need
to know it? (read svn book...)

- we need to think about what we do to get those patches into the trunk,
also, because we most often will want and need them there, also.

- rules for committing, also in people branches as far as possible
    - test first, and make sure your changes work (as long as it's
      possible -if you need to share broken code, because somebody
      else wants to help looking for the error, this is perfectly
      allowed, though)
    - should probably be tested in a clean chroot environment,
    - package build should be tested with pbuilder
    - linda and
    - lintian should be run against resulting packages and source tree)

- how will we handle branching and tagging in general? say:
   - when will we/Thomas make a main branch (in /branches/)?
       -> when we start to prepare for a release, then we should have a
          release branch which gets freezed, and only things planned for
          that release and bug/documentation fixes get applied
       -> when we go for some bigger, longer term changes, like
          fai-multi-distribution, or package splitting, or big cleaning 
          up of file locations, which we are not sure if we get them
          done for the next FAI major(say, non-bugfix) release, we'll
          probably need a main or
          people branch for it, depending on how many people will work
          on it. hmm, or depending on what? This is not already well
          thought out, but I am somehow unsure how to handle that case)


Comments? Ideas?

Henning
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://lists.uni-koeln.de/pipermail/linux-fai-devel/attachments/20051016/683c0903/attachment.bin