Mailing-List: contact users-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Subject: Re: tag individual files vs whole repo?
To: users@subversion.apache.org
References: <CAJvUf-A_Hh1x3zq1MDvQhR5mn3AH+YVYnB27gqNgmaq1ZbEiyw@mail.gmail.com>
From: Stefan Hett <stefan@egosoft.com>
Message-ID: <248bc441-9c6f-8c26-9f5f-1285d649e1f9@egosoft.com>
Date: Tue, 10 May 2016 22:10:51 +0200
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101
 Thunderbird/45.0
MIME-Version: 1.0
In-Reply-To: <CAJvUf-A_Hh1x3zq1MDvQhR5mn3AH+YVYnB27gqNgmaq1ZbEiyw@mail.gmail.com>
Content-Type: multipart/alternative;
 boundary="------------066A33700442D6A0BDD45FE7"
archived-at: Tue, 10 May 2016 20:11:05 -0000

This is a multi-part message in MIME format.
--------------066A33700442D6A0BDD45FE7
Content-Type: text/plain; charset=utf-8; format=flowed
Content-Transfer-Encoding: 7bit

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


--------------066A33700442D6A0BDD45FE7
Content-Type: text/html; charset=utf-8
Content-Transfer-Encoding: 7bit

<html>
  <head>
    <meta content="text/html; charset=utf-8" http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 5/10/2016 4:09 PM, Matt Garman
      wrote:<br>
    </div>
    <blockquote
cite="mid:CAJvUf-A_Hh1x3zq1MDvQhR5mn3AH+YVYnB27gqNgmaq1ZbEiyw@mail.gmail.com"
      type="cite">
      <pre wrap="">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.</pre>
    </blockquote>
    The case you are describing is certainly something where
    revision/file labels/tags would be beneficial.<br>
    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.<br>
    <br>
    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:<br>
    - proj/trunk is the latest version we are developing on<br>
    - proj/branches/1.x is created from trunk when version 1.0 is
    released<br>
    - proj/tags/1.0 is created from proj/branches/1.x at the same time<br>
    <br>
    Following work goes into proj/trunk - bugfixes are done in
    proj/branches/1.x.<br>
    At one point 1.1 is released from proj/branches/1.x and a tag is
    created (proj/tags/1.1).<br>
    <br>
    There are also occasions where we release directly from trunk
    skipping the creation of proj/branches/xxx.<br>
    <br>
    Hence the process is very much like the one the SVN project is
    using.<br>
    <br>
    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).<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <br>
    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.<br>
    <pre class="moz-signature" cols="72">-- 
Regards,
Stefan Hett</pre>
  </body>
</html>

--------------066A33700442D6A0BDD45FE7--