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.
You received this message because you are subscribed to the Google Groups
To post to this group, send email to email@example.com
To unsubscribe from this group, send email to
For more options, visit this group at