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?
Thanks!
Received on 2016-05-10 16:09:22 CEST