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/sortof does 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 at http://www.reviewboard.org/users/
To unsubscribe from this group, send email to 
For more options, visit this group at 

Reply via email to