Having a version that doesn't require an SCM is unlikely to happen in the
foreseeable future. We require an SCM to grab the full files so we can even
build the diffs. There's way too much that would have to be changed and
worked around if we were to remove this requirement.

I would much rather someone take over really making the ClearCase support
rock-solid. Not having access to a server to test and develop against,
maintaining this by ourselves is difficult at best.

Christian

-- 
Christian Hammond - chip...@chipx86.com
Review Board - http://www.reviewboard.org
VMware, Inc. - http://www.vmware.com


On Mon, Jan 25, 2010 at 4:44 PM, Sassan <sassan...@verifone.com> wrote:

> OK,
>
> 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:
> http://reviews.reviewboard.org/r/1197/
>
> 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
> free,
> partial implementation of RB in which the abstract diffs only live in
> RB
> 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
> receive the
> diff's and dumping them.
>
> Sassan
>
>
> 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
> > project.
> >
> > Christian
> >
> > --
> > 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
> > >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...@googlegr­oups.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
> 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