7 messages in com.perforce.revml[revml] Re: [VCS] VCS patch proposal ...
FromSent OnAttachments
Barrie Slaymaker30 Oct 2001 06:35 
Barrie Slaymaker30 Oct 2001 12:24 
PPry...@factset.com30 Oct 2001 14:25 
Barrie Slaymaker31 Oct 2001 08:01 
PPry...@factset.com01 Nov 2001 07:26 
Barrie Slaymaker01 Nov 2001 07:48 
Ed08 Nov 2001 12:19 
Subject:[revml] Re: [VCS] VCS patch proposal and release
From:Ed (ed@chronos.net)
Date:11/08/2001 12:19:04 PM
List:com.perforce.revml

I took a look at the VCS project early on (ie a few years ago) and it didn't seem to be a good fit for what our initial goals, developing RevML, had to do. The RevML project's sinced morphed in to a utility that supports RevML, called VCP, and which uses it extensively in it's test suite. Mildly ironic though it is, the core operations of VCP (copying between various repositories) don't use RevML, although you can copy from any of the two repositories so far in to or out of RevML.

I interpret this that you are conceptually implementing a DOM engine for your particular XML language. This is a normal and acceptable thing to do, particularly if there is a way of telling it to emit proper XML if an application should wish to. This implies that you might be interested to take a look at http://java.apache.org/ and SAX.

By the way, in your revml.dtd, I see elements that are intended to encode XML-unsafe characters. Is there a reason you're not using entities (&gt;) or CDATA (<!CDATA[>]>)?

That would be a useful utility, but it's not critical. I think that it is beyond question that diff-hist should be diff-hist.PL which generates the installable diff-hist, thankyou for this change.

If it's of interest, I have a Diff.pm that uses Algorithm::Diff and outputs in any of several common Unix diff formats, old-style, context and unified. It's meant to be extended, and I plan on putting on CPAN when I think of a good name for it, probably Text::Diff, not sure.

Here, you may be interested in looking at the code in VCS's vcsweb.cgi, which contains a diff-parser which generates a data structure. Once again, I would seek to integrate this so we have just one set of code.

I also need to throw together a VCP::Patch that knows how to parse and apply a unified diff, but I don't have immediate plans to make it understand lots of different formats.

I believe it should not take a diff as input at all, but a data structure. Unless of course it simply constructs one immediately, in classic polymorphic fashion. Otherwise you'd be duplicating code, the worst software-engineering sin known to man! ;-)

Not knowing the code, this strikes me as a place where File::Spec might be deployed usefully, either in the loop or searchINC() or modname2filename(). Probably already in there, just thought I'd mention it on the way by.

Actually, it's still useful in the VCS->class_load() method (see my VCS URI post), so thanks for this. It sounds like you're the best man to write the 3 lines of code, improving on this:

sub class_load { my $class = shift; my @path = split /::/, $class; $path[-1] .= '.pm'; # I assume this is always the case? require File::Spec::list2filename(@path); # or whatever the function is called! }

FWIW, VCP has a VCP::TestUtils that the test suites use to detect and configure the various SCMs (we only have two at this point:cvs and p4), and they skip tests for any not present. That way the modules get installed and might even work when the user one day installs the required SCM even if it wasn't present at VCP install time.

I proposed in another post today that this should have a sensible default but be admin-choosable. I believe that Peter has this subject in hand, however.

Have you looked into revML and the revml mailing list along with the VCP module from Barrie Slaymaker?

I've actually Cc:ed Barrie on this e-mail, and I'm hoping we can share ideas.

Yes, lets. And perhaps even some code :).

Heck, let's unify the projects! It'll probably end up as 25 lines of code for both projects, if we do it right. Of course, the dependency list might be quite impressive (XML, File::Spec, Text::Diff, ... ;-)

RevML solves a few issues, like encoding illegal XML characters and doing diffs and patches to encode change sets (so it doesn't have to copy entire files). VCP implements both "bootstrap" RevML files, which contain the entire content of the first revision of the file) and "incremental" RevML files, which contain the MD5 of the revision before the first revision in the RevML file and then jsut a diff -u to get from there to the first revision in the RevML file. RevML does not address the branching issue at this time, although there are some precocious declarations in the DTD that would like to one day.

Let's see how far we can go along this route. Delenda Code, as the great Cato might have said!

RevML wants to allow any repository to be wholely captured in a RevML file, or any useful subset of it. It does handle binary files and other things containing illegal characters, it's almost there with metadata (the execute bit is not passed through by VCP::*::cvs at the moment, for instance), and it's not thinking about branches and mapping branches between disparate repositories yet.

Sounds powerful.

VCS is a lot farther a long then when I last looked at it, I see a couple of areas where VCP and VCS might interface to eachother or share code: [snip] - VCP Currently supports VCS, Perforce, and RevML, and is getting VSS on board next. I'm upgrading IPC::Run to run on NT and hunting down Unix-only dependancies and shooting them (how violent, eh?). As soon as I can get VCP to pass it's tests on NT, there's a fellow just waiting to take a swing at VSS. Anyway, this might be another area for common effort. Does VCS do CVS (or anything else) on NT?

It does CVS. Whether it'll work on NT is basically up to NT, but it should. Try it! :-)

So, let's talk. I'll gladly explain any overobfuscated or underdocumented bits of VCP, and I'll peruse VCS over the next week or two. I see that CVS seems to be the main "example", is there a definitive list of other systems mentioned anywhere?

Any further feedback?

Regards, Ed