on moving tags

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

John A Meinel wrote:
| Aaron Bentley wrote:
|
|> I agree that there is an unfortunate overlap between filesystem
|> heirarchy terminology and geneological terminology.  As a result, we
|> have 'branches' and inside those branches, we have multiple 'revision
|> trees'.
|
| Do we actually have trees inside of bzr? I thought each branch was just
| a single line of development. Which may be similar to other branches.

That's what I mean about an unfortunate overlap.  Each 'branch' (line of
development) contains one or more 'trees' (snapshots of the working
directory at commit time).

|> More precise terms like 'line of descent' could be listed as alternates,
|> but we must use existing jargon where the meaning is reasonably similar.
|>
|
| Is it 'line of decent' or 'line of development'.

Both are applicable, but whatever is clearer to people is what we should
use.

| If people understand
| the former, no problem, but for me the later is more obvious. Decent
| sounds more like tracking what branches you came from/ancestry/etc.

In bzr, you don't track what branch you came from, only what revision
you came from.

If foo was branched from bar at revno 3, then foo and bar have common
ancestry up to revno 3.  After that, their ancestry diverges.

|> | At the very least I hope that bzr eschews within its CLI CVS's
|> | conflation
|> | of "branch tags" and "revision tags".
|>
|> The interesting thing is, you can represent a revision tag as a locked
|> branch.  So how much conflation is that, really?
|
|
| Well, a branch is somewhere that development is done. So a locked branch
| isn't much of a branch.

Locking hasn't been implemented, but it was proposed as an alternative
to Arch's --seal.  In bzr, instead of sealing, you'd lock the branch.
And if you needed to add bugfixes, instead of passing --versionfix,
you'd unlock the branch first.  Being able to unlock a branch (if
locking was a mistake) is a good feature that Arch doesn't offer.

| And since a tag is really just a name somewhere
| along the branch, I don't think it makes sense to call it a branch.

Sure.  Martin's trying make things as simple as possible, but no
simpler.  Using one concept for tags and branches is conceivable, but
not really desirable.

| Arch was pretty foolish in how it used the term "tag". It really was
| branch, I think it just grew up from tag, and was never fixed (until baz).

I thought of 'tag' in the 'you're it' sense.  But yeah, needlessly
confusing.  What was really silly was using 'branch' for the middle term
of version names like 'tla--devo--1.3'.

| But to respond to the original poster, that is pretty much what I was
| mentioning. There is a collection of files named by tagname, inside of
| which is a listing of what revisions they pointed to.

Actually, it's

tag -> addressible tree snapshot -> list of filenames and associated
content ids.  Revision's the wrong term for this.  Maybe we can call
particular pieces of content 'blobs' as git does.

| I think you need a
| little bit more meta-information, so that they also contain dates/etc
| for the ability to say "give me the tag as it was defined on this date".
| Because I think '.' should be valid in the tag name itself, I think we
| can once again turn to our handy ':' character. So tagname:1,
| tagname-10.1.2:2 are valid values, indicating that you want a specific
| version of the tag.

I don't see versioning tags as important.  It adds a lot of
complication, and moving tags is something that should only be done when
you've made a mistake.  I'd rather leave it out.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.5 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCiiZn0F+nu1YWqI0RAn2jAJ99fO+ETk9f7FEQT+3Wxs96JjmE3wCfb5cv
vp+Au4KMhos1E7Lauw/DwjA=
=U58U
-----END PGP SIGNATURE-----