Any chance Review-Board will work with IronPython?  (yes, the Vault
libraries are .NET)



On Aug 18, 11:01 am, schuijo <schu...@gmail.com> wrote:
> Christian,
>
> It does, but requires a login first.  It has a SOAP interface defined,
> but SourceGear highly recommends NOT using it.
>
> I have a Python question for you (sorry, until a couple weeks ago I
> never even heard of Python ;-)
>
> It seems the (time-wise) expensive steps in this Vault integration are
> the Java VM for the Java client, and the login step each time the CLC
> is called.  I'm thinking that creating some form of a DLL interface
> that will stay logged into Vault would greatly improve our response
> times.  Does Python have support for DLL integration?  COM?
>
> Thanks!
>
> On Aug 17, 1:23 pm, Christian Hammond <chip...@chipx86.com> wrote:
>
>
>
> > Hi John,
>
> > Yeah, that seems a bit expensive, slow, and unscalable...
>
> > Does Vault happen to have built-in support for looking at raw files from a
> > web page, given a filename and revision? If so, it can take advantage of the
> > new raw URL field I'm adding for Git.
>
> > If not, we'll need to figure out a solution that doesn't require Java.
>
> > Christian
>
> > --
> > Christian Hammond - chip...@chipx86.com
> > Review Board -http://www.review-board.org
> > VMware, Inc. -http://www.vmware.com
>
> > On Mon, Aug 17, 2009 at 8:31 AM, schuijo <schu...@gmail.com> wrote:
>
> > > Thanks Christian, that seemed to be the case.
>
> > > Just a note to anyone attempting to integrate with Sourcegear's Vault:
> > > I originally attempted to use their Java CLC for portability, but each
> > > file in the review needed to contact the Vault server twice and each
> > > contact would (re)spawn the Java VM which was very expensive time
> > > wise.  I'm currently testing the system with the Win32 CLC and it is
> > > slow, but usable.  I'm considering looking into the possiblity of
> > > batching the contacts to the Vault server...time permitting.
>
> > > Thanks again for all your help Christian!!
> > > John
>
> > > On Aug 12, 7:21 pm, Christian Hammond <chip...@chipx86.com> wrote:
> > > > Hi,
>
> > > > It's possible that when you use the cache function, it's returning
> > > > cached data from some older, broken attempt. If you reenable the
> > > > caching and then fully clear the cache and try again, does it work?
>
> > > > Christian
>
> > > > On Wednesday, August 12, 2009, schuijo <schu...@gmail.com> wrote:
>
> > > > > More:
>
> > > > > I traced the source of that parameter to get_original_file() in
> > > > > diffutils.py.  When I bypass the cache lookup and just return the
> > > > > result of the fetch_file() sub-function I can display diffs properly,
> > > > > although response is very slow as expected.  Any ideas where I should
> > > > > look to determine why the cache contents would be wrong?  (I do have
> > > > > the memcached server installed)
>
> > > > > Thanks!
>
> > > > > On Aug 12, 5:54 pm, schuijo <schu...@gmail.com> wrote:
> > > > >> I think I am very close now, but I have a problem in diffutils.py.
> > > > >> The second parameter in the parse() function (file I believe) 
> > > > >> contains
> > > > >> some invalid data, where does this get populated?
>
> > > > >> Thanks!
>
> > > > >> On Aug 11, 2:29 pm, Christian Hammond <chip...@chipx86.com> wrote:
>
> > > > >> > Hi,
>
> > > > >> > Path is the path to the file in the repository. If the path in the
> > > diff is
> > > > >> > always going to be absolute, then you can completely ignore
> > > base_path and
> > > > >> > just use path. We use base_path for Subversion, where the filenames
> > > in the
> > > > >> > diff are relative to the current directory rather than the root of
> > > the
> > > > >> > repository. We then append path to base_path to generate that
> > > absolute path.
>
> > > > >> > Christian
>
> > > > >> > --
> > > > >> > Christian Hammond - chip...@chipx86.com
> > > > >> > Review Board -http://www.review-board.org
> > > > >> > VMware, Inc. -http://www.vmware.com
>
> > > > >> > On Tue, Aug 11, 2009 at 10:54 AM, schuijo <schu...@gmail.com>
> > > wrote:
>
> > > > >> > > Christian,
>
> > > > >> > > Ok...I think I've severely bitten off more than I can chew, but
> > > I'm
> > > > >> > > trying to forge my way through this.  I've been modifying
> > > post-review
> > > > >> > > to add Vault support, and appear to have it working to the point
> > > where
> > > > >> > > it seems to be attempting to contact the Vault server while
> > > uploading
> > > > >> > > the diff.  The point I'm a little lost/confused on is how to
> > > represent
> > > > >> > > Vault in the RepositoryInfo class.  What exactly are path and
> > > > >> > > base_path and how are they used?  (hopefully this will help me to
> > > > >> > > determine what need to be populated in there for Vault)
>
> > > > >> > > Thanks!
>
> > > > >> > > On Jul 28, 4:05 pm, Christian Hammond <chip...@chipx86.com>
> > > wrote:
> > > > >> > > > There are some threads on the mailing list about doing this, 
> > > > >> > > > but
> > > they're
> > > > >> > > not
> > > > >> > > > exactly step-by-step tutorials. The best reference right now is
> > > the
> > > > >> > > > scmtools/*.py files.
>
> > > > >> > > > Basically, you'll create a subclass of SCMTool that does the
> > > following:
>
> > > > >> > > > 1) Grabs a file from a repository, given a file path and
> > > revision.
> > > > >> > > > 2) Provide a DiffParser subclass that handles pulling out
> > > filenames and
> > > > >> > > > revisions and any other necessary data from a diff (most of the
> > > code for
> > > > >> > > all
> > > > >> > > > this is common, so you just hook into things -- see the other
> > > files for
> > > > >> > > > examples).
> > > > >> > > > 3) If Vault has a concept of server-side changesets (you
> > > register a
> > > > >> > > > changeset with a description, and other data, and the server
> > > always knows
> > > > >> > > > what you have checked out on the client) then you'll need to
> > > implement
> > > > >> > > > get_changeset().
>
> > > > >> > > > So the general model is that this code will have three classes:
>
> > > > >> > > > 1) VaultTool
> > > > >> > > > 2) VaultDiffParser
> > > > >> > > > 3) VaultClient
>
> > > > >> > > > VaultTool will be a subclass of SCMTool and will be what Review
> > > Board
> > > > >> > > talks
> > > > >> > > > to.
>
> > > > >> > > > VaultDiffParser will be a subclass of DiffParser and will
> > > override
> > > > >> > > functions
> > > > >> > > > to parse revision info out of a diff.
>
> > > > >> > > > VaultClient will be a wrapper around the command line tool,
> > > which
> > > > >> > > > VaultClient will talk to.
>
> > > > >> > > > Now, let's talk diffs. Many revision control systems provide
> > > tools that
> > > > >> > > > generate diffs unsuitable for Review Board, and sometimes we
> > > have to work
> > > > >> > > > around them. If vault's tool generates a diff containing
> > > revision
> > > > >> > > > information for a file that can be used to pull data from the
> > > repository,
> > > > >> > > > then we're good. If not, you'll need to implement this in
> > > post-review.
>
> > > > --
> > > > --
> > > > Christian Hammond - chip...@chipx86.com
> > > > Review Board -http://www.review-board.org
> > > > VMware, Inc. -http://www.vmware.com
--~--~---------~--~----~------------~-------~--~----~
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