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 t
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 t
Hi!
On Tuesday 12 May 2009 04:41:06 Christian Hammond wrote:
> As for the DB change, we have a nice database migration system in place.
> You pretty much need to just make the change to the appropriate Model
> class(es) and then add an Evolution definition (see reviews/evolutions/*.py
> for exam
On Mon, May 11, 2009 at 2:32 PM, Thilo-Alexander Ginkel <
thilo.gin...@gmail.com> wrote:
>
> On May 11, 9:55 pm, Christian Hammond wrote:
> > With this SCM, is the change identifier a server-stored ID that contains
> the
> > description and other information for Review Board to parse? Or is it
>
On May 11, 9:55 pm, Christian Hammond wrote:
> With this SCM, is the change identifier a server-stored ID that contains the
> description and other information for Review Board to parse? Or is it more
> like an atomic ID representing that change that gets pushed to the server
> when committed?
T
With this SCM, is the change identifier a server-stored ID that contains the
description and other information for Review Board to parse? Or is it more
like an atomic ID representing that change that gets pushed to the server
when committed?
If the former, and if you want to support pulling that i
