tag individual files vs whole repo?

[Matt Garman <ma...@gmail.com>]

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!

Re: tag individual files vs whole repo?

[Stefan Hett <st...@egosoft.com>]

On 5/10/2016 4:09 PM, 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.
The case you are describing is certainly something where revision/file 
labels/tags would be beneficial.
However, tbh this is a case/situation I never came across yet in my 
entire time I've been developing software. Certainly the fact that I do 
not have much experience with Git contributes to that.

I take it that the reason for that is that I never thought about tagging 
just "bugfixes". I've used tags only ever to tag completed versions. 
Bugfixes for past versions, I've always worked on a separate branch. Aka:
- proj/trunk is the latest version we are developing on
- proj/branches/1.x is created from trunk when version 1.0 is released
- proj/tags/1.0 is created from proj/branches/1.x at the same time

Following work goes into proj/trunk - bugfixes are done in 
proj/branches/1.x.
At one point 1.1 is released from proj/branches/1.x and a tag is created 
(proj/tags/1.1).

There are also occasions where we release directly from trunk skipping 
the creation of proj/branches/xxx.

Hence the process is very much like the one the SVN project is using.

To simplify our workload we are utilizing CruiseControl and set-up a 
task there which runs daily and automatically merges any changes from 
proj/branches/1.x back to trunk. That way we have to fix issues which 
exist in 1.x only once (in the 1.x branch) rather than twice (1.x + trunk).

That said, for us tags are always representing the 
source-/resource-state of a whole version and never of a separate 
fixes/change - these things are always done using branches. The release 
manager works with the branch he explicitly switched to (aka: 
branches/1.x) and is pulling in other branches which contain fixes, so 
mistakes as you are describing are almost impossible to happen here in 
practice.

The one big obvious advantage of that process and the point of always 
tagging a whole repository (or better said: a whole project state) is 
that everything with that tag is in it's fixed state. There are never 
combinations of multiple tags, which are likely to occur in cases you 
would end up if you tag files/revisions. So the code and resource state 
is straight forward when you tag an entire repository. That's the main 
advantage I see here, but it's on the other side also the main limiting 
factor which reduces flexibility of what you can do.

To be more precise: If you would use a system/procesdure where you 
create your own release from a combination of separate tags, you could 
easily compose any kind of project variation. In practice however this 
would come to its limit sooner or later where the different tags deviate 
so much from one another that any kind of attempt to merge the different 
states would be unfeasible.

-- 
Regards,
Stefan Hett

Re: tag individual files vs whole repo?

[Branko Čibej <br...@apache.org>]

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