On 10.05.2016 16:09, Matt Garman wrote:
> Consider this scenario: our project has concurrent releases, R8 and
> R9. These releases have been indicated in the repo by some means,
> either a tag or a branch.
> Now, we need to bugfix R8 only. Specifically, we want to do a release
> R8.1 that does not include R9 features.
>
> Through some means, e.g. mis-communication, developer error, whatever,
> the developer does the bugfix on R9, instead of R8. And he tags his
> fix "bug_xyz_fix". Now, the release manager will update his build to
> the "bug_xyz_fix" label, and inadvertently release the bugfix plus the
> R9 changes, which we wanted to avoid.
>
> This is one potential problem with tagging a whole repo, rather than
> individual files. In this particular case, it may be possible that
> the one file that changed for the R8 bugfix is also perfectly valid
> for R9. So in this case, it arguably makes sense to tag only the one
> changed file, rather than the whole repo.
>
> I've seen this asked before ("how to tag only individual files"). I
> know it's possible to force svn into doing it, but it's going against
> the design intent of the tool. And I feel that whole-repo tagging is
> generally better, but the above example is one case where that may not
> hold. So what I'm really asking is:
> - What are the rational reasons to prefer whole-repo tagging
> versus individual file tagging? I'm having trouble coming up with
> example cases to support whole-repo tagging even though my gut says
> it's better.
> - In general, what kind of automation (e.g. convenience scripts,
> hooks, etc) have you built on top of subversion to help avoid process
> errors like the one described above?
One solution is the one that we use in Subversion development: we have
separate branches for separate release lines; for example, currently new
development happens on
.../subversion/trunk
and we have two active release branches:
.../subverison/branches/1.8.x
.../subversion/branches/1.9.x
Bug fixes for problems found on one of the release branches are
developed on trunk, then merged (cherry-picked) or otherwise backported
to the appropriate release branch. Releases are cut and tagged from the
branches.
-- Brane
