Further info below.
On 03/02/2014 19:41, Bill Somerville wrote:
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).
Further to this, normal practice is to do development on a "main line"
under repo/trunk/... or repo/wsjtx/trunk/... and, when ready, to make a
release a tag is made from a copy of trunk in repo/tags/wsjtx-ver/... or
repo/wsjtx/tags/ver/... respectively (this needn't necessarily be one
revision of trunk - a tag can be made from a mixed revision workspace
for example when a late breaking development fails tests at the last
minute).
Then fixes are released by copying the tag back to branches e.g.
repo/tags/wsjtx-ver/... -> repo/branches/wsjtx-ver-minor/... or
repo/wsjtx/tags/ver/... -> repo/wsjtx/branches/ver-minor/... before
committing changes.
Then fix releases are merged back to the trunk (and possible newer fix
release branches) then tagged and released from the branch.
A lot of this is moot in a "product" that doesn't offer support on
anything but the latest release, but nevertheless using the method is
good, particularly if you need to move to a different VCS as the
migration tools usually expect this type of structure.
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
