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 -~----------~----~----~----~------~----~------~--~---
