I am beginning to see Dan's point of view.
think I am going to put off the idea of getting RB to work with
ClearCase at this point.
I have discovered a reference to "/vobs" substring as part of the file
path in postreview.
# Removing anything before the last /vobs
# because it may be repeated.
elem_path_idx = elem_path.rfind("/vobs")
if elem_path_idx != -1:
elem_path = elem_path[elem_path_idx:len(elem_path)].strip("\"")
This apparently assumes that the vob server is running Linux/Unix
which is not the case here.
I could try to fix this but I am not sure where else this assumption
has been made.
However I do like the uploading of an abstract diff file on the client
side as implemented in:
Also in our software change process, code reviews are not always
the final step before changes become part of the core.
So technically speaking we would not even want approved changes
to be checked automatically after a code review approval !!
I was wondering how difficult would it be to have an entirely SCM
partial implementation of RB in which the abstract diffs only live in
where they go through the review/modify/approve cycle without ever
having to come back to an SCM.
Or if we must have one, to setup some sort of mock SCM object
(Using svn, git or anything else) only to interface with RB, to
diff's and dumping them.
On Jan 16, 4:36 pm, Christian Hammond <chip...@chipx86.com> wrote:
> Indeed.. Shame IBM isn't using Review Board (at least, I don't know if they
> are). Maybe they could give us a license or some code or something.
> Little by little, I'm setting up some build/test VMs, and I'm hoping to get
> to a point where we can have better post-review and Review Board tests
> against installed servers of various types. But it's a long, time-consuming
> Christian Hammond - chip...@chipx86.com
> Review Board -http://www.reviewboard.org
> VMware, Inc. -http://www.vmware.com
> On Sat, Jan 16, 2010 at 1:26 PM, Dan Savilonis <d...@n-cube.org> wrote:
> > I don't know how similarly people use Clearcase, but I am fairly
> > certain that the way my organization uses it is very non-standard. The
> > typical review scenario would be to review modified code in a view,
> > not checked in code.
> > Fitting Clearcase's model into Reviewboard is a bit of square in round
> > hole problem, though at the most basic level you can do the same thing
> > that's done for other SCM systems: provide a base revision set and
> > diff against it. Some of the stuff you mentioned is all possible,
> > though it doesn't fit nicely into the ReviewBoard model as-is. Feel
> > free to start up a thread in the dev mailing list and I'll help with
> > whatever I can. However, I personally think your time might be better
> > spent getting rid of Clearcase from your organization :)
> > Christian, you'd likely need a mighty generous donor to get a
> > Clearcase license. You'll also probably regret it once you try to set
> > the beast up...
> > On Jan 15, 8:02 pm, Sassan <sassan...@verifone.com> wrote:
> > > At least for ClearCase, most places have a standard naming convention
> > > for their views and/or config specs.
> > > Either way all it takes is for the client to prompt for and pass two
> > > view tags (strings) or config specs (small ascii files) in order for
> > > the web server to start the "before" and "after" views of the change
> > > locally on the server host and generate the diff... no file copy will
> > > be needed.
> > > This might be easier than dealing with verson extended pathnames.
> > > Dealing with directory changes (moving files from one place to
> > > another / renaming the files) is more difficult and we will need to
> > > use the ClearCase Object ID strings instead of file path names.
> > > On Jan 15, 5:51 pm, Chris Clark <chris.cl...@ingres.com> wrote:
> > > > Thilo-Alexander Ginkel wrote:
> > > > > On Friday 15 January 2010 23:20:32 Sassan wrote:
> > > > >> I am also thinking it might be a good idea to add a repository
> > > > >> independent base functionality to the post-review script where it is
> > > > >> handed the root directory of two source trees, before and after the
> > > > >> change and it will then just compare the files and post a review.
> > > > >> This way anyone with any source repository can just create the
> > before
> > > > >> and after soure trees outside RB and pass the roots of the source
> > > > >> trees to the post-review script for posting.
> > > > > This won't work as Review Board needs to be able to access the
> > respective SCM
> > > > > repository from the server-side to apply the posted diff to the base
> > revision.
> > > > For the server this is true. RE the client,
> >http://reviews.reviewboard.org/r/1197/sortofdoes this. It allows any
> > > > diff to be sent to reviewboard .... but it had better be a valid diff
> > :-)
> > > > Chris- Hide quoted text -
> > > > - Show quoted text -
> > --
> > Want to help the Review Board project? Donate today at
> > 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- Hide quoted text -
> - Show quoted text -
Want to help the Review Board project? Donate today at
Happy user? Let us know at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to
For more options, visit this group at