On Friday 15 May 2009 14:46:27 Christian Hammond wrote: > First, I want to be 100% sure that we're having the same definition of this > field. This field represents an upstream server-side ID that is tied to > that specific set of changes, and will exist up to and possibly past the > point where the change is committed, regardless of how many updates are > made to that review request.
As I understand from the code, Perforce has a feature called changeset - a named entity with usual attributes of a commit: author, changes description etc, - which hasn't been integrated into development mainline. The possible difference between a real commit and a changeset is that commit is unchangeable, it's already published, while a changeset may be changed before it actually committed. Changesets are identified by changenums on Perforce side. In order to implement 'post-review' strategy I also need to refer a specific commit (with author, changes description, file diff) identified by its ID. > The upstream changeset information should > contain useful information, such as the description or bugs closed. Once a > changenum is set on a review request, it should not change. Well, since post-review approach works when a commit is already in the repository, there's no need to change this identifier in a corresponding review request -- all subsequent fixes if any are to be committed separately and can have separate review requests. Thus I think re-use of `changenum' field is possible, it serves quite similar purposes in case of Perforce "changesets" and commit/revision IDs. > So right now, raw SQL would be the only current option (assuming it can be > done in a standard way), but if we do it it must be thoroughly tested with > every database type Django supports. I would say that my preferred option > would be to patch django-evolution to support a ChangeFieldType that > converted between certain types, and then use that. That could be unit > tested and support could be tuned for each database type. Plus it's more > reusable and other projects could benefit. yes, I think it would be more reasonable to implement proper support in Django Evolution. But I don't have enough experience with all that code to solve the task myself. So I guess I won't implement proper data migration from numeric changenums to string change_ids right now. Alexey Morozov. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "reviewboard" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/reviewboard?hl=en -~----------~----~----~----~------~----~------~--~---
