Community
Participate
Working Groups
Users have problems accessing historic revision, as the required timestamps are not user friendly. I propose to support 'tags' to map revisions by mapping a string to a timestamp. I propose that CDO maintains a regular EMF/CDO object with a feature containing a map from string to long. This allows to create 'tags' that refer to historic revisions by storing the timestamp of the revision. The benefit of storing the tags in a regular EMF object are: * easy to implement * works with any CDO store * tags itself get revisioned in audit mode and one can get a historic tag with an audit view. And if bug 256649 is implemented even who created the tag. * tags can be enumerated (via regular EMF API) e.g. to display them in an UI. I also propose that CDO offers an API to create and query (return the EMap) the tags.
I think that named tags for commits (not revisions) are a good thing. The solution you proposed should already be possible. You can create a model with that standard EClass with a map feature. After a commit you can ask transaction.getLastCommitTime() and use the resulting long value in your map. If that's what you mean I'd close this bugzilla as WORKSFORME. But I think that special CDO API for this makes sense as well. In this case we can keep this bug open as a reminder. Would you like to contribute a patch?
(In reply to comment #1) > I think that named tags for commits (not revisions) are a good thing. The > solution you proposed should already be possible. You can create a model with > that standard EClass with a map feature. After a commit you can ask > transaction.getLastCommitTime() and use the resulting long value in your map. > If that's what you mean I'd close this bugzilla as WORKSFORME. > > But I think that special CDO API for this makes sense as well. In this case we > can keep this bug open as a reminder. Would you like to contribute a patch? It's the latter. We talked on the phone yesterday and he is already implementing the custom solution. However, I thought it might be a good idea to introduce tagging into the CDO API - this might also be convenient for the UI. Maybe Vik is also interested in this?
(In reply to comment #2) > (In reply to comment #1) > > I think that named tags for commits (not revisions) are a good thing. The > > solution you proposed should already be possible. You can create a model with > > that standard EClass with a map feature. After a commit you can ask > > transaction.getLastCommitTime() and use the resulting long value in your map. > > If that's what you mean I'd close this bugzilla as WORKSFORME. > > > > But I think that special CDO API for this makes sense as well. In this case we > > can keep this bug open as a reminder. Would you like to contribute a patch? > > It's the latter. We talked on the phone yesterday and he is already > implementing the custom solution. However, I thought it might be a good idea to > introduce tagging into the CDO API - this might also be convenient for the UI. > Maybe Vik is also interested in this? We aren't using the Audit mode in our solution, but I also find this enhacement quite convenient.
(In reply to comment #0) > Users have problems accessing historic revision, as the required timestamps are > not user friendly. Do you mean version number as a tag? Or it is "free" tagging by giving name to some revision? We also deal with historical revision and in order to make historical revisions understandable for user, we introduced class which holds version number. However our desire is to have versions created and stored on server, instead of changing versions on client side and putting it on custom class. So if it is request for tags AKA version numbers, then it would be nice if server could introduce versioning strategy with predefined versions storage (let say in system resource) and access to it from client. Versioning strategy could be changeable by custom code to define versions numbering style and scope of versioned elements. What do you think?
I think this is really moreabout assigning names to timestamps (and branches in the future).
Both proposals do not have to be contradictionary: a. We could invent the concept of the named commit: Every commit is assigned an internal name - and we could also have the naming scheme configurable as Egidijus proposed. We could also add an API for assigning aliases (and maybe a comment?) to the named versions, so one can assign user-readable tags. b. We could just stick to only assign tags to timestamps. In this case, if the user wants version numbers, he would have to create the logic to assign version number-tags himself. Just as a remark: I like the idea of an additional comment for a commit or tag operation, because that makes the history (e.g. import jobs etc.) more understandable.
Sounds good, seems related with bug 256649
My original intent was to associate a tag with a timestamp to allow the user to use names for (historic) audit views. As today the audit view needs a timestamp and the timestamp is hard/impossible to memorize for end users. I like the idea of comments, too. It should be easy to create a small struct that not only contains the timestamp, but also a comment. I don't think we need a tag for every commit, so I initially proposed to get the timestamp of a commit that needs taging by asking the transaction and then create another small transaction and commit the tag with the comment itself.
(In reply to comment #8) > I don't think we need a tag for every commit, so I initially proposed to get > the timestamp of a commit that needs taging by asking the transaction and then > create another small transaction and commit the tag with the comment itself. Is there a reason for having a separate transaction for the tag operation? Wouldn't it make sense to have an API like transaction = session.openTransaction(); transaction.setTag("Import-2009-12-16"); transaction.setComment("Import of foobar data."); // do something with the resource .... transaction.commit(); // <- commit changes and set tag for immediate setting tags. The question is, where should be put API calls to tag commits post-hoc. session.addTag(timestamp, tagname, comment) maybe?
Why shouldn't a timestamp have more than one name? The only restriction should be that a name is unique per branch (currently per repository, as we have only one main branch). I'd put the management API for tags into the session as it is really not related with objects or transactions (other than transactions also produce timestamps). If we associate tags with commits upfront, we should enable the user to specify more than one.
Isn't repository too big scope for uniqueness? Repository can contain many logical projects (logical scope) and it will be to restrictive to allow unique tag names among these projects.
I would like to avoid making any assumptions on usage-specific scopes like projects, houses, etc... IMHO these are application-managed string policies.
(In reply to comment #9) > Is there a reason for having a separate transaction for the tag operation? > Wouldn't it make sense to have an API like > > transaction = session.openTransaction(); > transaction.setTag("Import-2009-12-16"); > transaction.setComment("Import of foobar data."); > // do something with the resource .... > transaction.commit(); // <- commit changes and set tag > > for immediate setting tags. The reason that I proposed a separate transaction was that: - one could want to tag a timestamp after the fact (e.g. after a QA step) - the person who creates tags is a different one than the one that commited the changes (e.g. QA approved)
(In reply to comment #10) > Why shouldn't a timestamp have more than one name? The only restriction should > be that a name is unique per branch (currently per repository, as we have only > one main branch). With my proposes solution one could create as many tags with the same timestamp as one likes. One can also change the timestamp (retag) which is useful if e.g. an application should always work on the latest "released" QA approved version of the repo. This could be done by reassigning the latest QA approved timestamp to the "released" tag. > I'd put the management API for tags into the session as it is really not > related with objects or transactions (other than transactions also produce > timestamps). As it would change or add new objects to the repo I would keep it on a CDO transaction object rather than a session.
(In reply to comment #11) > Isn't repository too big scope for uniqueness? Repository can contain many > logical projects (logical scope) and it will be to restrictive to allow unique > tag names among these projects. I see it similar to a SVN repository that can contain many projects as well, but the tags are repository wide. It's also easier to implement. I would not implement anything more complex unless someone has already a real use case for the more complex use case where she can not use multiple repositories.
(In reply to comment #14) > > I'd put the management API for tags into the session as it is really not > > related with objects or transactions (other than transactions also produce > > timestamps). > > As it would change or add new objects to the repo I would keep it on a CDO > transaction object rather than a session. That's true only under the premise that we use E/CDOObjects to model the tags. But I don't like that idea as it only add complication rather than value.
(In reply to comment #16) > (In reply to comment #14) > > > I'd put the management API for tags into the session as it is really not > > > related with objects or transactions (other than transactions also produce > > > timestamps). > > > > As it would change or add new objects to the repo I would keep it on a CDO > > transaction object rather than a session. > > That's true only under the premise that we use E/CDOObjects to model the tags. > But I don't like that idea as it only add complication rather than value. As long as it's visible who created or modified a tag (via bug 256649) I would not care if it's implemented with E/CDOObjects or not, but via E/CDOObjects and the current audit mode we would get that for free. We have a requirement where a part of the system we build must only access an approved version of the repository and it would be easy to do that with the proposed way via re-taging. But if re-taging is used then the history of who created and modified a tag is important to us. That's why I came up with the idea to use regular E/CDOObjects to model the taging and just wrap it in a nice API for creating, changing, deleting and querying tags.
> As long as it's visible who created or modified a tag (via bug 256649) I would > not care if it's implemented with E/CDOObjects or not, but via E/CDOObjects and > the current audit mode we would get that for free. That information is in the session, so we *could* use it. > We have a requirement where a part of the system we build must only access an > approved version of the repository and it would be easy to do that with the > proposed way via re-taging. But if re-taging is used then the history of who > created and modified a tag is important to us. That's why I came up with the > idea to use regular E/CDOObjects to model the taging and just wrap it in a nice > API for creating, changing, deleting and querying tags. I don't think that we'll have a history of tag operations, only info about the last operation, e.g. time/userID.
(In reply to comment #18) > I don't think that we'll have a history of tag operations, only info about > the last operation, e.g. time/userID. As I outlined we have a requirement to track re-taging and it looks like your proposal would not support that. If the tags are implemented E/CDOObjects we would get that for free. Why do you not like the idea to model the taging infrastructure with E/CDOObjects? It looks to me that it would add some value after all. I would hate to have to roll my own taging facility, that's why I opened this bug for discussions and requirement gathering.
> As I outlined we have a requirement to track re-taging and it looks like your > proposal would not support that. No, I don't think this is of general usefulness. But others might convince me ;-) > If the tags are implemented E/CDOObjects we > would get that for free. Why do you not like the idea to model the taging > infrastructure with E/CDOObjects? It looks to me that it would add some value > after all. For example you'd always have to setup a CDOView to do anything with the tags. > I would hate to have to roll my own taging facility, that's why I opened this > bug for discussions and requirement gathering. If you really have this very special requirement it would be rather trivial to create a model that perfectly suits your needs and map it to the tags that we will maintain internally.
(In reply to comment #20) > > As I outlined we have a requirement to track re-taging and it looks like > > your proposal would not support that. > > No, I don't think this is of general usefulness. But others might convince > me ;-) > > > If the tags are implemented E/CDOObjects we > > would get that for free. Why do you not like the idea to model the taging > > infrastructure with E/CDOObjects? It looks to me that it would add some > > value after all. > > For example you'd always have to setup a CDOView to do anything with the tags. Yes, that's why I would add the read API to CDOView and the write API to CDOTransaction. I also think it's important if you query the tags on an audit view that you can only see the tags made until the time that the audit view uses. Any modifications after the time should be hidden. I think that would be necessary to preserve the way audit mode works. If your implementation would be used, then a tag that existed in an audit view but was revised later would point to an invalid timestamp (relative to the audit view that is used to read the tag). I think that is undesirable. > > I would hate to have to roll my own taging facility, that's why I opened > > this bug for discussions and requirement gathering. > > If you really have this very special requirement it would be rather trivial > to create a model that perfectly suits your needs and map it to the tags > that we will maintain internally. As outlined above your strategy looses information, so I could not use it at all and would have to completely roll my own.
As I said, I'dd like to hear what others think. I still think versioning/auditing the tags is irritating for users who expect this to work as in CVS or Subversion. My current vote is -1 for that, sorry ;-(
(In reply to comment #22) > As I said, I'dd like to hear what others think. I still think > versioning/auditing the tags is irritating for users who expect this to work as > in CVS or Subversion. My current vote is -1 for that, sorry ;-( Actually SVN does exactly what I asked for. If you do a 'svn ls -r <revision> svn+ssh://repo/tags' then you will only see the tags that were created or changed before and including the revision that was specified. And as you can remove and recreate entries (usually directories) in svn+ssh://repo/tags 'svn ls svn+ssh://repo/tags' will show what's current and there a directory with the same tag name can contain different files than the one in revision <revision>. If you doubt that, test it for yourself. $ svn ls -r 50000 http://svn.apache.org/repos/asf/spamassassin/tags | wc -l 45 $ svn ls -r 60000 http://svn.apache.org/repos/asf/spamassassin/tags | wc -l 46 $ svn ls http://svn.apache.org/repos/asf/spamassassin/tags | wc -l 963
Ok, give me some time to think about it. Feedback from others is highly appreciated ;-)
Hi All, We are developing similar functionality to put comment on commit/transaction/timestamp. These comments are editable. I believe principals are very similar to Lothar's proposal for tags. It is not possible to read data + comment in the same AuditView. Comment has different lifecycle/history and normally user wants to see latest version of comment/tag even for the very old commit. A requirement to put tag after commit looks reasonable also. Change or remove tag also. Finally I am personally confused where is disagreement :) Seems like we moved too far into technical side while haven't found agreement on requirements. Regards, Saulius (In reply to comment #24) > Ok, give me some time to think about it. Feedback from others is highly > appreciated ;-)
(In reply to comment #25) > Finally I am personally confused where is disagreement :) Seems like we moved > too far into technical side while haven't found agreement on requirements. I agree. We also need this feature. I don't understand the details, but I should vote for a simple and open solution.
Rebasing all outstanding enhancements requests to version 4.0
Moving all open enhancement requests to 4.1
Moving all open issues to 4.2. Open bugs can be ported to 4.1 maintenance after they've been fixed in master.
Moving all outstanding enhancements to 4.3
Moving all open enhancement requests to 4.4
Moving all open bugzillas to 4.5.
Moving all unaddressed bugzillas to 4.6.
Moving all open bugs to 4.7
Moving all unresolved issues to version 4.8-
Moving all unresolved issues to version 4.9
This bugzilla is closest to what I'm currently implementing. I'll not implement everything that was proposed here initially, or how in detail it was proposed. But I'm sure you'll be happy with it...
Moving to 4.13.
