> It would be interesting to hear from other people on this list about their
> workflows.

I use svn here and for the most part I just work away on multiple
changes in a single workspace. When I finish a particular part, I'll
post a review for only those files. Once the review is done, I commit
only those files and continue my changes.

Another approach I was considering is to check out a new project when
working on something that does not require changes in my current
workspace. This will make creating patches easier and let me focus on
the task at hand (instead of having other changes get in the way).

We do most of our reviews by applying the patch to a fresh project to
catch any missing files or other compile errors. It also lets us use
our IDE to better understand and go over changes.

I like the idea of using Git, it's a good suggestion.

--
Arthur Kalmenson



On Tue, Dec 30, 2008 at 6:35 PM, Christian Hammond <chip...@chipx86.com> wrote:
> Hi Tino,
>
> I'm working on user manuals for Review Board, which I'm hoping to finish up
> for 1.0. Right now, I'm about half way through a detailed Administration
> Guide. I'll try to keep in mind the workflows suggestion for the Users
> Guide.
>
> It would be interesting to hear from other people on this list about their
> workflows.
>
> Christian
>
> --
> Christian Hammond - chip...@chipx86.com
> VMware, Inc.
>
>
> On Tue, Dec 30, 2008 at 3:12 PM, Tino Breddin <tino.bred...@googlemail.com>
> wrote:
>>
>> Hi Christian,
>> Thanks for the detailed explanation of your workflow. I was just looking
>> into using git on the client side too, since I'm familiar with it and patch
>> management is much easier just as you describe.
>> Nevertheless I'd also like to see how other approaches which use
>> subversion instead of git would work.
>> I think having different workflows explained in the documentation on the
>> wiki would greatly help Review Board newcomers to get into it more quickly.
>> Having such a overview certainly helped me to more easily grasp the power
>> and freedom of git.
>> Tino
>>
>> On Tue, Dec 30, 2008 at 1:50 PM, Christian Hammond <chip...@chipx86.com>
>> wrote:
>>>
>>> Hey Tino,
>>>
>>> What a lot of us are starting to do both at VMware and within Review
>>> Board is to use git as a form of patch management. Git can wrap around both
>>> SVN and Perforce, allowing us to do all our work within Git and then push to
>>> the proper VCS.
>>>
>>> My workflow is generally as follows:
>>>
>>> 1) Create a new topic branch for whatever I'm working on. In git, these
>>> are really cheap and easy to create, and you can switch the active topic
>>> branch easily, all in one single checkout.
>>> 2) Make as many commits as I need until I'm ready to post for review.
>>> 3) Make sure my topic branch is branched off of "master" (which should
>>> represent HEAD in your VCS, requiring a "rebase" to it if not).
>>> 4) Run post-review
>>> 5) After approval, squash the branch down to one commit and run "git svn
>>> dcommit" to push to Subversion.
>>>
>>> It seems like there's extra work in there, and there is, but it also
>>> makes for a much more flexible environment. I have right now in my one
>>> checkout of Review Board some 6 or 7 development branches I'm doing work on.
>>>
>>> Git definitely has a learning curve, but in my opinion, it's very much
>>> worth it.
>>>
>>> Christian
>>>
>>> --
>>> Christian Hammond - chip...@chipx86.com
>>> VMware, Inc.
>>>
>>>
>>> On Tue, Dec 30, 2008 at 10:22 AM, Tino Breddin
>>> <tino.bred...@googlemail.com> wrote:
>>>>
>>>> I agree, my question isn't exactly related to reviewboard and I should
>>>> have been more specific. The vcs in this use-case is Subversion.
>>>> Having multiple subversion checkouts might be a solution but suffers
>>>> from a lot of overhead too. Thanks for the hint about the patch-
>>>> management system Quilt, I'll definitely look into that.
>>>>
>>>> I am wondering what "good development practices" evolved out of using
>>>> Subversion and Review Board.
>>>>
>>>> Cheers,
>>>> Tino
>>>>
>>>> On Dec 29, 11:11 pm, "Christian Hammond" <chip...@chipx86.com> wrote:
>>>> > Hi Tino,
>>>> >
>>>> > This greatly depends on the revision control system, and isn't really
>>>> > specific to Review Board. If you have separate independent changes you
>>>> > want
>>>> > to post to review, you need to do multiple checkouts or use some sort
>>>> > of a
>>>> > patch-management system (like Quilt). This is a more general issue of
>>>> > how
>>>> > you do development on multiple things at once when dealing with the
>>>> > same
>>>> > files.
>>>> >
>>>> > Christian
>>>> >
>>>> > --
>>>> > Christian Hammond - chip...@chipx86.com
>>>> > VMware, Inc.
>>>> >
>>>> > On Mon, Dec 29, 2008 at 5:10 PM, Tino Breddin
>>>> > <tino.bred...@googlemail.com>wrote:
>>>> >
>>>> >
>>>> >
>>>> > > Hi,
>>>> >
>>>> > > I am wondering how you handle changes in the same file which don't
>>>> > > really fit into the same review request. So you would have a change
>>>> > > for which you create a review request. Then you change other things
>>>> > > in
>>>> > > the same file and would like to create a review request for these
>>>> > > changes only. Is it necessary to create branches for each of the
>>>> > > changes, wait until the review is complete, commit changes and then
>>>> > > merge branches into trunk?
>>>> >
>>>> > > Thank, Tino
>>>>
>>>
>>>
>>>
>>
>>
>>
>
>
> >
>

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"reviewboard" group.
To post to this group, send email to reviewboard@googlegroups.com
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