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 

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 reviewboard@googlegroups.com
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to