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
Received on 2016-05-10 22:11:05 CEST