I think that what I'm talking about is the same thing that Eduardo called
"Remodelling diff versioning".  Does that seem right to you?




On Tue, Oct 26, 2010 at 7:17 PM, Andrew Schwartz <aschwa...@gmail.com>wrote:

> Christian,
>
> Sorry for letting this thread slide for so long.
>
> I'm talking about a review request being for a series of changesets.  In
> our case, we often will split a single feature change into small, easily
> reviewed changesets.  It would be nice to be able to put all of these
> changesets into a single review request.
>
> Does that make sense?
>
>
> On Sun, Aug 1, 2010 at 3:49 PM, Christian Hammond <chip...@chipx86.com>wrote:
>
>> I'm not sure I fully understand the functionality you're asking for,
>> Andrew. Are we just talking about creating new diffs to replace the old
>> ones? Isn't that what we have today? Are you asking for that + branch
>> tracking?
>>
>>
>> Christian
>>
>> --
>> Christian Hammond - chip...@chipx86.com
>> Review Board - http://www.reviewboard.org
>> VMware, Inc. - http://www.vmware.com
>>
>>
>> On Thu, Jul 29, 2010 at 8:07 PM, Eduardo Felipe <
>> eduardofelip...@gmail.com> wrote:
>>
>>> Andrew,
>>>
>>> I'm afraid that won't be possible with the code I'm writing. I'm
>>> basing this on a post-commit style of review. In this scenario, you
>>> would write a new commit E that fixes the issues mentioned on the
>>> review, instead of rewriting the patches.
>>>
>>> The model you are suggesting is harder to do on something other than
>>> git, e.g. mercurial, unless you use mqueues to do it.
>>>
>>> I could even write the code, but I don't think I'll be able to do it
>>> in time for the end of the Summer of Code Program.
>>>
>>> Christian, would you like to comment on this issue?
>>>
>>> Cheers,
>>>
>>> Eduardo.
>>>
>>> On Thu, Jul 29, 2010 at 1:55 PM, Andrew Schwartz <aschwa...@gmail.com>
>>> wrote:
>>> > N
>>> >
>>> > On Tue, Jul 27, 2010 at 4:05 PM, Eduardo Felipe <
>>> eduardofelip...@gmail.com>
>>> > wrote:
>>> >>
>>> >> Sure!
>>> >>
>>> >> I am working on making the support for DVCS better by implementing the
>>> >> following:
>>> >>
>>> >> Remote branch tracking:
>>> >>
>>> >> Based on the notion of feature branches one could build around the
>>> >> notion of long lived reviews that could be updated as the code is
>>> >> updated, all in the Web UI, without having to post another review and
>>> >> lose the context information. As such reviews could be used to
>>> >> document coding decisions before a branch is integrated in the main
>>> >> line, and could be automatically closed once the branch is merged
>>> >> back. My implementation focus mainly on Git for the time being, but it
>>> >> will also support Mercurial before it's ready to go.
>>> >>
>>> >> Remodeling diff versioning:
>>> >>
>>> >> Currently when a new review is created on Review Board, it takes the
>>> >> uploaded patch, infer the oldest committed version referenced by the
>>> >> patch and applies the patch on top of it, creating a new version. It
>>> >> then goes ahead and mark that patch as version one. If the user
>>> >> uploads a new patch, version two is created, and with that the
>>> >> possibility of seeing just what changed between the two versions,
>>> >> therefore reviewing the part, not the whole.
>>> >>
>>> >> With the new workflow upon submitting a patch to be reviewed, instead
>>> >> of just loading the submitted patch and marking it as version one,
>>> >> Review Board would fetch the diff for every incremental revision from
>>> >> the oldest version present in the diff to the newest, apply it on top
>>> >> of the head and mark that as a version of the patch, in practice
>>> >> creating a version containing all changes from the base up to that
>>> >> point. It would also store information about which commits formed that
>>> >> partial patch to display later.
>>> >>
>>> >> If the repository that holds the commits is not accessible to
>>> >> ReviewBoard then in order to take advantage of this feature you'll
>>> >> have to use post-review from the command line, so it can create a
>>> >> bundle containing all the information necessary for this view.
>>> >>
>>> >
>>> > Sounds promising.  If a review response involves creating a new set of
>>> > changesets to replace the old set of changesets, will there by a
>>> concept of
>>> > sub-versions?  For instance:
>>> >
>>> > Say A is the head of the current master repository.  I'm submitting
>>> three
>>> > related changesets for review, B, C and D.  Then, as a result of the
>>> review,
>>> > I now want to update the diffs with B', C' and D'.  Will there be any
>>> > mechanism for doing this and easily seeing that B' is related to B,
>>> etc.?
>>> >
>>> >>
>>> >> I expect this code to be done by the second week of August (that's
>>> >> when the Summer of Code ends), and to be integrated on a new version
>>> >> when Christian agrees with everything I've done, hehehe.
>>> >>
>>> >> Cheers,
>>> >>
>>> >> Eduardo.
>>> >>
>>> >> On Tue, Jul 27, 2010 at 4:37 PM, Christian Hammond <
>>> chip...@chipx86.com>
>>> >> wrote:
>>> >> > Eduardo, can you give a summary of what you're working on?
>>> >> >
>>> >> > Christian
>>> >> >
>>> >> > --
>>> >> > Christian Hammond - chip...@chipx86.com
>>> >> > Review Board - http://www.reviewboard.org
>>> >> > VMware, Inc. - http://www.vmware.com
>>> >> >
>>> >> >
>>> >> > On Tue, Jul 27, 2010 at 12:33 PM, Andrew <aschwa...@gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> Hi all.  Please let me know what's going on with DVCS and Review
>>> >> >> Board.  I know that there are ways to make it work (as we are in my
>>> >> >> organization), but it would be nice for it to be better integrated
>>> in
>>> >> >> the project with reviewing multiple changesets, etc.  Thanks.
>>> >> >>
>>> >> >> On Jul 20, 5:40 pm, Andrew <aschwa...@gmail.com> wrote:
>>> >> >> > I'm wondering if there has been any progress on theDVCSfront.
>>>  I'd
>>> >> >> > be very interested in the current design.  Is one of the GSOC
>>> >> >> > students
>>> >> >> > actively working on this?
>>> >> >> >
>>> >> >> > On Jun 2, 6:08 pm, Christian Hammond <chip...@chipx86.com>
>>> wrote:
>>> >> >> >
>>> >> >> > > Hi James,
>>> >> >> >
>>> >> >> > > Today, each logical change is meant to have its own review
>>> request.
>>> >> >> > > If
>>> >> >> > > you
>>> >> >> > > have three things that are related but are separately worked
>>> on,
>>> >> >> > > each
>>> >> >> > > should
>>> >> >> > > be put up for review separately. There's no notion of a review
>>> >> >> > > request
>>> >> >> > > that
>>> >> >> > > encompasses several different changes. I personally think this
>>> is
>>> >> >> > > good, as
>>> >> >> > > it keeps it organized and keeps things smaller.
>>> >> >> >
>>> >> >> > > Where things may change over the next several months is how
>>> diffs
>>> >> >> > > are
>>> >> >> > > handled when used with aDVCSlike Git. In those cases, it makes
>>> >> >> > > sense
>>> >> >> > > to be
>>> >> >> > > able to have a review request for one change but with several
>>> >> >> > > iterative
>>> >> >> > > diffs leading up to that one change. It would still be one
>>> logical
>>> >> >> > > change,
>>> >> >> > > but with multiple diffs instead of one big diff. I don't know
>>> how
>>> >> >> > > well
>>> >> >> > > this
>>> >> >> > > concept would really apply in the SVN guess. I suspect it
>>> wouldn't.
>>> >> >> >
>>> >> >> > > Now, I'm not fully sure I understand how your project is
>>> organized.
>>> >> >> > > Is
>>> >> >> > > each
>>> >> >> > > Java component in a different repository? If not, can't one
>>> diff be
>>> >> >> > > generated that has all the changes to all the components, and
>>> then
>>> >> >> > > put
>>> >> >> > > that
>>> >> >> > > up as one review request?
>>> >> >> >
>>> >> >> > > If they are indeed in different repositories, then what you'd
>>> need
>>> >> >> > > is
>>> >> >> > > a way
>>> >> >> > > to have one review request that spans repositories. This is
>>> >> >> > > something
>>> >> >> > > that,
>>> >> >> > > for many reasons, we wouldn't be doing, so you'd have to have
>>> one
>>> >> >> > > review
>>> >> >> > > request per repository.
>>> >> >> >
>>> >> >> > > I don't really understand your second request. It sounds like
>>> >> >> > > something that
>>> >> >> > > could be solved by aDVCSsolution, or multiple checkouts of your
>>> >> >> > > repository.
>>> >> >> >
>>> >> >> > > For the third request, this is something that's not really on
>>> the
>>> >> >> > > radar for
>>> >> >> > > a release right now. In order to do it right, I think we need
>>> to do
>>> >> >> > > more
>>> >> >> > > than revision ranges (especially forDVCSsystems where it's not
>>> >> >> > > actually a
>>> >> >> > > numeric range). I'd like to do it correctly if we do it, and
>>> that
>>> >> >> > > will
>>> >> >> > > take
>>> >> >> > > some time and planning.
>>> >> >> >
>>> >> >> > > Christian
>>> >> >> >
>>> >> >> > > --
>>> >> >> > > Christian Hammond - chip...@chipx86.com
>>> >> >> > > Review Board -http://www.reviewboard.org
>>> >> >> > > VMware, Inc. -http://www.vmware.com
>>> >> >> >
>>> >> >> > > On Thu, May 20, 2010 at 12:41 AM, james tong
>>> >> >> > > <james_tong...@yahoo.com.cn>wrote:
>>> >> >> >
>>> >> >> > > > Hi, all,
>>> >> >> > > > My team now is using the ReviewBoard-1.0.6 which is running
>>> on
>>> >> >> > > > the
>>> >> >> > > > Cent-OS
>>> >> >> > > > server. And this is really fantastic software which help us a
>>> lot
>>> >> >> > > > for code
>>> >> >> > > > review.
>>> >> >> > > > However, we also found some troubles when doing review.
>>> >> >> >
>>> >> >> > > > First, In our project, we need to update the code in more
>>> than
>>> >> >> > > > one
>>> >> >> > > > components (java project), so we may generate several diff
>>> files
>>> >> >> > > > for
>>> >> >> > > > one
>>> >> >> > > > main function. And we find that it is impossible (or it is
>>> >> >> > > > possible
>>> >> >> > > > but we
>>> >> >> > > > did not find that?) to upload these diff files in the same
>>> review
>>> >> >> > > > request.
>>> >> >> > > > Then we have to create several review requests for the same
>>> main
>>> >> >> > > > function.
>>> >> >> > > > So, I send this email and hope to know what is others' way
>>> for
>>> >> >> > > > this
>>> >> >> > > > problem?
>>> >> >> > > > I think this may be a common case.
>>> >> >> >
>>> >> >> > > > Second, for some case, we may need to change the same class
>>> for
>>> >> >> > > > two
>>> >> >> > > > main
>>> >> >> > > > functions at the same period (during the week by different
>>> team
>>> >> >> > > > members), so
>>> >> >> > > > how to generate diff file and create the review request for
>>> this
>>> >> >> > > > case? (Our
>>> >> >> > > > review request is created base on main function changes, and
>>> for
>>> >> >> > > > this case,
>>> >> >> > > > one review request will contain the changes for other main
>>> >> >> > > > function,
>>> >> >> > > > there
>>> >> >> > > > may be some confusing). I know this might not be in the scope
>>> of
>>> >> >> > > > this mail
>>> >> >> > > > list, but still hope to get some useful suggestion.
>>> >> >> >
>>> >> >> > > >  Third, we are using svn as the repository. And we want to
>>> know
>>> >> >> > > > that
>>> >> >> > > > when
>>> >> >> > > > we can simply input the revision numbers in the web GUI for
>>> >> >> > > > creating
>>> >> >> > > > a
>>> >> >> > > > review request without uploading the diff file. :-)
>>> >> >> >
>>> >> >> > > > Many Thanks
>>> >> >> > > > BR//
>>> >> >> >
>>> >> >> > > > --------------
>>> >> >> > > > Best Regards!
>>> >> >> > > > James.Tong
>>> >> >> > > > 童熙
>>> >> >> >
>>> >> >> > > > --
>>> >> >> > > > Want to help the Review Board project? Donate today at
>>> >> >> > > >http://www.reviewboard.org/donate/
>>> >> >> > > > Happy user? Let us know athttp://www.reviewboard.org/users/
>>> >> >> > > > -~----------~----~----~----~------~----~------~--~---
>>> >> >> > > > To unsubscribe from this group, send email to
>>> >> >> > > >
>>> >> >> > > >
>>> >> >> > > > reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
>>> <reviewboard%2bunsubscr...@googlegroups.com<reviewboard%252bunsubscr...@googlegroups.com>
>>> >
>>> >> >> > > > For more options, visit this group at
>>> >> >> > > >http://groups.google.com/group/reviewboard?hl=en
>>> >> >>
>>> >> >> --
>>> >> >> Want to help the Review Board project? Donate today at
>>> >> >> http://www.reviewboard.org/donate/
>>> >> >> Happy user? Let us know at http://www.reviewboard.org/users/
>>> >> >> -~----------~----~----~----~------~----~------~--~---
>>> >> >> To unsubscribe from this group, send email to
>>> >> >> reviewboard+unsubscr...@googlegroups.com<reviewboard%2bunsubscr...@googlegroups.com>
>>> >> >> For more options, visit this group at
>>> >> >> http://groups.google.com/group/reviewboard?hl=en
>>> >> >
>>> >
>>> >
>>>
>>
>>
>

-- 
Want to help the Review Board project? Donate today at 
http://www.reviewboard.org/donate/
Happy user? Let us know at http://www.reviewboard.org/users/
-~----------~----~----~----~------~----~------~--~---
To unsubscribe from this group, send email to 
reviewboard+unsubscr...@googlegroups.com
For more options, visit this group at 
http://groups.google.com/group/reviewboard?hl=en

Reply via email to