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>
>> >> > > > 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
>> >
>
>

-- 
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