tags

[John A Meinel]

Aaron Bentley wrote:
> 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.

I'm trying to avoid downloading the entire tag file, just to get 2 new
entries. I'm okay with actually reading the file.

> 
>>>> 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.

Did Martin actually suggest a new tree revision? I know that is what
Gustavo did. I was actually thinking that we *would* create a new tag
revision. I just wasn't calling it a revision to keep it conceptually
separate from the tree revision.

To clarify: Yes, I want to create a new unique tag revision for every
modification to the set of tags. I just want them decoupled from the set
of tree revisions.

> 
>>>> 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

That is what I had in mind. Take the new one, and you can revert if you
need to.

However, thinking back to why we want conflicts: if there was a
disagreement on a change, the user is disallowed from committing until
they have told bzr that they resolved the problem. (Either accepting the
new value, or reverting to the old one, or some combination thereof).

We probably do want conflicts for tags, since they fall into this same
situation.

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/4b8abbab/attachment.pgp