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.

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