tags

[Aaron Bentley]

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

John A Meinel wrote:
> I agree that tag id needs to be something new. But I think we only need:
> 
> supersedes: tag at id-098098, tag at id-321321
> 
> Because you are defining an ancestry. You don't have to define every
> single entry.

If you do it that way, then you don't have all the information you need,
and you must hit previous revisions of the file.  I thought we were
trying to avoid that.

>>Aren't these tag ids behaving a lot like revisions?  Wouldn't it be
>>better to just use revisions?  The combination of a revision ID and a
>>tag-name will be unique.
> 
> 
> No, it won't. Because I might have set a tag to something. And then set
> it to something else without ever committing a new revision.

Both you and martin have proposed systems in which setting a tag entails
creating a new revision.  In his, it's a new tree revision.  In yours,
it's a tag-metadata revision.  Either way, I don't think this scenario
applies.

> There was also very strong support that modifications to tags should
> take effect instantly. (There should be no 'commit' phase).

If tags are versioned, there's a new revision somewhere each time tags
change.

>>I think it would be fine to dump a file in the working directory for
>>conflict resolution.
> 
> 
> +0 on it for me. Its okay, but it isn't great. And the user wouldn't be
> likely to maintain any invariants we would want. They could easily
> generate invalid rio, have 2 copies of the same tag text, change
> ordering, etc. When all we really need is to have them say "X=Y".

I never said it had to be in the internal representation.  I don't think
it does.  We could actually include log messages and everything.

> With a simple 'the new one takes precedence' we don't have the same
> problem of conflicts.

So when there is a conflict, and you must take a value, it's better to
take OTHER than THIS, because it's easier for the user to restore their
changes than to

I'm not sure that this is a case in which we must take a value.

> Because of the need to create an entire conflict handling solution, that
> users need to learn, I'm not really for an explicit conflict. I do
> realize that conflicts are good in this situation, as per our earlier
> discussion of non-textual conflicts. I just can't think of a decent ui,
> so I thought conflict-less tags might actually be easier to work with.

How about the merge command emits: "Conflicting values for foo-tag.
Taking new value from remote branch.  To restore your previous value, do
'bzr revert-tag foo-tag'"

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

iD8DBQFD+fGC0F+nu1YWqI0RAuGsAJ0awK5cI2vmZbuUHy4EdurEWTs/NgCeMO9U
BvEvJxSQ5sbOPrkXETBtZtk=
=cyRi
-----END PGP SIGNATURE-----