tags

[John A Meinel]

Aaron Bentley wrote:
> John A Meinel wrote:
>>> Aaron Bentley wrote:
>>>
>>> Actually, I was thinking to decouple the tag identifiers from revision
>>> identifiers for the 'placed-in' type field.
>>>
>>> So doing something like:
>>>
>>> tag-name: bzr-0.8-foo
>>> tag-target: revision at id-123123123
>>> tag-id: tag at id-456456456
>>> superceeds: tag at id-234234234
>>>
>>> Yes, it re-implements the weave logic, which was why I was thinking to
>>> have it be inside the weave information.
> 
> So say we have this.  Then we merge, and we get:
> 
> tag-name: bzr-0.8-foo
> tag-target: revision at id-435345
> tag-id: tag at id-098098
> supersedes: tag at id-234234234, tag at id-456456456
> 
> When we decide we want to reassign the tag back to its first value, we get:
> 
> tag-name: bzr-0.8-foo
> tag-target: revision at id-123123123
> tag-id: tag at id-321321
> supersedes: tag at id-234234234, tag at id-456456456, tag at id-098098
> 
> Note that the tag-id must be something new, not tag at id-234234234,
> because tag at id-098098 will beat tag at id-234234234.

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.

> 
> 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. And while
you can say that "well you didn't really mean the first one", I might
have done it the first way for 2 years, and then updated it later. And
it really did mean the first one, and people have merged from my branch,
and now I really do mean the second one.

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

> 
>>> And then we are having people edit a file under .bzr, which is something
>>> we really have been wanting to avoid.
> 
> 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".

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

> 
>>> This means there is no chance for a conflict. If I merge you, and I
>>> haven't seen your tag before, I get your tag. But if I override your
>>> tag, that means I've seen it, and I want a different value for the tag.
>>> And if you merge me after I've superseded your tag, then you will get my
>>> tag value.
> 
> I think when two people change a value FROM the same value TO different
> values, that should be treated as a conflict, even if you set the value
> to OTHER.  People should be notified about that kind of change.
> 
> Aaron

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.

But I can agree that if I change the value, and someone else changes the
value, it should probably conflict. Damn....

John
=:->

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060220/073b4b1b/attachment.pgp