subversion-users mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@apache.org>
Subject Re: tag individual files vs whole repo?
Date Tue, 10 May 2016 14:24:44 GMT
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

Mime
View raw message