On 03/02/2014 19:32, Joe Taylor wrote:
Hi Bill,
Hi Joe,
If necessary, any bug fix or minor tweak to v1.3 should be done in the
newly created .../tags/wsjtx-1.3 branch. (But this should be resisted,
if possible.) New work should definitely go into .../branches/wsjtx.
Normally .../tags/... should not be committed to. Instead make a new
branch ../branches/... by copying the tag to something like
.../branches/wsjtx-1.3.1/... and then commit fixes to there with merges
into .../branches/wsjtx/... if appropriate.
I checked in the SVN "bible" before making the tag this morning and
found this text:
"Both [tags and branches] are just ordinary directories that are
created by copying. Just as with branches, the only reason a copied
directory is a “tag” is because humans have decided to treat it that
way: as long as nobody ever commits to the directory, it forever
remains a snapshot. If people start committing to it, it becomes a
branch."
Their intent, I believe, is that tags should not be branches (despite
the fact that tags and branches in SVN are implemented the same way).
They would become so if commits were allowed to tags. They do go on to
say that some sites use commit hooks to physically ban commits to
anything under tags, we don't need that but the concept is important
because it allows a tag to be named the same as the branch it snapshots.
That way you can create a branch called, say wsjtx-1.3.1, and commit
away to it while developing; but the tag wsjtx-1.3.1 is a snapshot of
what actually went out of the door after development was completed and
should not change.
So summarising:
A branch represents a future release.
A tag represents what was actually released (other minor milestones can
be tagged too like release candidates).
But of course: Yes, we can do it the way you suggest, if everyone
prefers.
-- Joe
73
Bill
G4WJS.
_______________________________________________
Wsjt-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/wsjt-devel
