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