[ On Monday, May 13, 2002 at 10:31:36 (-0700), Glew, Andy wrote: ]
> Subject: RE: merge mode for XML
>
> > > Motivation: schema changes in most existing relational databases are
> > > onerous.
> >
> > For very good reason.
>
> And what is that reaso
This thread is a die hard, but it is still the best conversation on the list
;)
sean.
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Peter Ring
> Sent: Tuesday, May 14, 2002 7:16 PM
> To: [EMAIL PROTECTED]
> Subject: R
s
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Glew, Andy
Sent: 13. maj 2002 19:32
To: [EMAIL PROTECTED]; Glew, Andy
Cc: Gary Bisaga
Subject: RE: merge mode for XML
> > Motivation: schema changes in most existing relational databases are
&
> > Motivation: schema changes in most existing relational databases are
> > onerous.
>
> For very good reason.
And what is that reason?
OK, I admit that some RDBMS applications in production
need stability - just like some systems software applications
(the kind Greg seems to work on, the kind
[ On Monday, May 6, 2002 at 07:58:09 (-0500), Sean Hager wrote: ]
> Subject: RE: merge mode for XML
>
>
> Actually pattern matching would put the users at the mercy
> of CVS more then extension ( really I mean wild card )
> matching.
Wildcard matching *is* pattern matching
--- Sean Hager <[EMAIL PROTECTED]> wrote:
> but only unix files have magic file numbers correct?
No, I have "file" working on Win2k.
If, however, a system doesn't have magic files, CVS
can fallback on pattern matching filenames to set the
initial behaviours upon "cvs add". The alternative
would
> I had understood "pattern matching" to be "pattern
> matching the name, not the contents, of the file". In
> this context, pattern matching would be an extended
> form of extenstion matching.
>
> OTOH, the pattern matching you mention is more like
> the magic file. I actually think this is an
--- Sean Hager <[EMAIL PROTECTED]> wrote:
> Actually pattern matching would put the users at the
> mercy
> of CVS more then extension ( really I mean wild
> card )
> matching. Pattern matching could be very
> unreliable and
> produce different results based on the content of
> the
> document
> I disargee. Doing this would force a policy onto CVS
> users where such a policy isn't really necessary.
>
> I think using extensions for any decision making is
> bad.Don't you think it would be bad to force the
> same diff/merge onto several files that had no
> extension?
>
> There's tw
In <[EMAIL PROTECTED]> [EMAIL PROTECTED] (Greg A. Woods) writes:
>It could be a good idea, if it were modified slightly. Since the type
>of content in a CVS RCS file revision can change from one revision to
>another the type of merge tool must be declared in a newphrase in each
>deltatext sectio
No doubt that's why nobody ever does it the other way on planet Earth.
Except, maybe, apache MIME magic. Or the "file" test.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
--- Paul Sander <[EMAIL PROTECTED]> wrote:
> >--- Forwarded mail from [EMAIL PROTECTED]
>
> >Greg is talking about the second issue. I have an
> >inkling keeping this info on a per-version basis
> won't
> >work but I haven't come up with anything
> substantial.
>
> Here's one:
>
> - Create a n
>--- Forwarded mail from [EMAIL PROTECTED]
>Greg is talking about the second issue. I have an
>inkling keeping this info on a per-version basis won't
>work but I haven't come up with anything substantial.
Here's one:
- Create a new file and check in a few versions on the trunk.
- Create a bran
>--- Forwarded mail from [EMAIL PROTECTED]
>> > > No. Not on extension, but based on *regular
>> expressions*, or at least
>> > > shell-style pattern matching expressions.
>> Extensions are too
>> > > simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore)
>> >
>> > Extensions would
>--- Forwarded mail from [EMAIL PROTECTED]
>[ On Friday, May 3, 2002 at 14:49:11 (-0500), Sean Hager wrote: ]
>> Subject: RE: merge mode for XML
>>
>>
>>
>> > No. Not on extension, but based on *regular expressions*, or at least
>> > shell-style
>--- Forwarded mail from [EMAIL PROTECTED]
>> Yeah. That'd be a cool feature. But then, CVS will no longer be a
>> standalone program. If you move the repository to another server
>> where the modules are missing, how would you expect CVS to behave?
>The plugins would be part of the m
--- Sean Hager <[EMAIL PROTECTED]> wrote:
> on earth, extension matching would be fine. Unless
> you have rogue
> developers that "try" and break the system by
> changing file formation while
> keeping extensions the same (save it as a jpg, but
> it is really a gif
> format) you should not have a
--- Sean Hager <[EMAIL PROTECTED]> wrote:
> > No. Not on extension, but based on *regular
> expressions*, or at least
> > shell-style pattern matching expressions.
> Extensions are too
> > simplistic. (c.f. CVSROOT/cvswrappers,
> CVSROOT/cvsignore)
>
> Extensions would work fine, pat
On Fri, May 03, 2002 at 04:43:11PM -0400, Greg A. Woods wrote:
> [ On Friday, May 3, 2002 at 14:49:11 (-0500), Sean Hager wrote: ]
> > Subject: RE: merge mode for XML
> > > No. Not on extension, but based on *regular expressions*, or at least
> > > shell-style patt
>
> > > No. Not on extension, but based on *regular
> expressions*, or at least
> > > shell-style pattern matching expressions.
> Extensions are too
> > > simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore)
> >
> > Extensions would work fine, pattern matching is overkill.
>
> Neit
[ On Friday, May 3, 2002 at 14:49:11 (-0500), Sean Hager wrote: ]
> Subject: RE: merge mode for XML
>
>
>
> > No. Not on extension, but based on *regular expressions*, or at least
> > shell-style pattern matching expressions. Extensions are too
> &
> Yeah. That'd be a cool feature. But then, CVS will no longer be a
> standalone program. If you move the repository to another server
> where the modules are missing, how would you expect CVS to behave?
The plugins would be part of the module, so if you moved the module to
another CV
> No. Not on extension, but based on *regular expressions*, or at least
> shell-style pattern matching expressions. Extensions are too
> simplistic. (c.f. CVSROOT/cvswrappers, CVSROOT/cvsignore)
Extensions would work fine, pattern matching is overkill.
> Yes. Some mechanisms l
[ On Wednesday, May 1, 2002 at 13:33:08 (-0700), Glew, Andy wrote: ]
> Subject: RE: merge mode for XML
>
> Well, I wrote Perl-SQL, a relational database system that
> is self-schematizing - where every record can define its own schema,
> with its own fields.
Yeah, that sounds l
[ On , May 2, 2002 at 09:33:45 (+0200), Lee Sau Dan wrote: ]
> Subject: Re: merge mode for XML
>
> >>>>> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes:
>
> Paul> A better implementation would be to code a symbolic name for
> Paul>
> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes:
>> If CVS had away to use modular plug in "diff" and "merge"
>> programs, we could setup a wrapper file that would
>> automatically diff/merge the file differently based on the
>> extension. e.g.:
>>
>> *.xml xml_dm *.
Hi, Greg:
Greg A. Woods wrote:
> [ On Wednesday, May 1, 2002 at 11:34:02 (-0400), Gary Bisaga wrote: ]
>
>>Subject: RE: merge mode for XML
>>
>>Good point, Noel. At my last job we had a partner we were required to
>>connect to, and it was a job getting even an exam
> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes:
Paul> A better implementation would be to code a symbolic name for
Paul> the merge tool in a newphrase in the admin section the RCS
Paul> file, and look up that symbolic name on the client to locate
Paul> the proper tool.
Go
[Greg Woods]:
>... conversations about XML and DTDs ...
> ...
> "well formed" by definition should mean in conformance to a
> pre-existing DTD!
> ...
> Do you build relational databases without defining a schema?
Well, I wrote Perl-SQL, a relational database system that
is self-schematizing -
> "Sean" == Sean Hager <[EMAIL PROTECTED]> writes:
Sean> I agree that XML is overkill, but the truth is that it is
Sean> here to stay.
Sean> XML is fastly becoming excepted as the defacto standard for
.
"accepted"? :)
Sean> If CVS h
ace.html
Kind regards
Peter Ring
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Gary Bisaga
Sent: 1. maj 2002 17:12
To: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
Sorry, this strikes me as just a little bit extreme. I agree t
[ On Wednesday, May 1, 2002 at 11:34:02 (-0400), Gary Bisaga wrote: ]
> Subject: RE: merge mode for XML
>
> Good point, Noel. At my last job we had a partner we were required to
> connect to, and it was a job getting even an example XML document out of
> them, let alone a DTD or sc
[ On Wednesday, May 1, 2002 at 11:11:32 (-0400), Gary Bisaga wrote: ]
> Subject: RE: merge mode for XML
>
> Sorry, this strikes me as just a little bit extreme. I agree that you ought
> to write DTDs or schemas (just yesterday I had to make one of our developers
> do so, and our o
:25 AM
To: Gary Bisaga; CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
Not only that, but in the end it is the client who
decides the "real" semantics of the document with or
without DTDs and Schemas.
Noel
--- Gary Bisaga <[EMAIL PROTECTED]> wrote:
> Sorry, this
ut there
> are realities of life.
>
> <>< gary
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Wednesday, May 01, 2002 1:56 AM
> To: Peter Ring
> Cc: CVS-II Discussion Mailing List
> S
riginal Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of
Greg A. Woods
Sent: Wednesday, May 01, 2002 1:56 AM
To: Peter Ring
Cc: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
> There's a class of simple XML documents that live and
> die without
[ On Wednesday, May 1, 2002 at 00:04:39 (+0200), Peter Ring wrote: ]
> Subject: RE: merge mode for XML
>
> SGML and XML files are really just serialized representations
> of parse trees, infosets, and an infoset can be serialized in
> many equivalent ways.
Hmmm it's jus
kind regards
Peter Ring
-Original Message-
From: Greg A. Woods [mailto:[EMAIL PROTECTED]]
Sent: 30. april 2002 19:09
To: Peter Ring
Cc: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
[ On Monday, April 29, 2002 at 08:31:24 (+0200), Peter Ring wrote: ]
> Subject: RE:
gt; subprogram architecture into CVS. Then we could implement an XML
> wrapper.
>
> sean.
>
>
>> -Original Message-
>> From: Paul Sander [mailto:[EMAIL PROTECTED]]
>> Sent: Monday, April 29, 2002 12:43 PM
>> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
&
[ On Monday, April 29, 2002 at 08:31:24 (+0200), Peter Ring wrote: ]
> Subject: RE: merge mode for XML
>
I sort of agree with the logic of the arguments for SGML and its
derrivatives, but I find the rhetoric about it being "the only choice
because it's the best there is"
> Don't hold your breath. Even the biggest proponents
> of this idea have
> not yet come up with working code as a solid
> proposal -- only what
> amounts to no more than a functional specification,
> and one that in my
> opinion contains several concerns for existing CVS
> users. Note too that
[ On Tuesday, April 30, 2002 at 07:43:21 (-0500), Sean Hager wrote: ]
> Subject: RE: merge mode for XML
>
> Thanks for offering up the samples Paul. I read through last Septembers
> thread on "giving up cvs". I see that I stirred up an old debate here (man
> you guys re
ent an XML wrapper.
sean.
> -Original Message-
> From: Paul Sander [mailto:[EMAIL PROTECTED]]
> Sent: Monday, April 29, 2002 12:43 PM
> To: [EMAIL PROTECTED]; [EMAIL PROTECTED]
> Subject: RE: merge mode for XML
>
>
> Once again, take a look at message ID#
> [EMAIL
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> In any case if you re-read what I wrote a little
> more carefully you'll
> note that I'm still only talking about XML, using
> HTML only as an
> example (because it uses the same syntax). Since
> all the XML parsers I
> know of are very much unrela
[ On Monday, April 29, 2002 at 19:47:12 (-0700), Noel Yap wrote: ]
> Subject: RE: merge mode for XML
>
> --- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> > [ On Monday, April 29, 2002 at 13:25:48 (-0700),
> > Noel Yap wrote: ]
> > > Subject: RE: mer
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> [ On Monday, April 29, 2002 at 13:25:48 (-0700),
> Noel Yap wrote: ]
> > Subject: RE: merge mode for XML
> >
> > In theory, this is easy to do, but in practice I
> have
> > seen browsers act differen
[ On Monday, April 29, 2002 at 13:25:48 (-0700), Noel Yap wrote: ]
> Subject: RE: merge mode for XML
>
> In theory, this is easy to do, but in practice I have
> seen browsers act differently due to whitespace that
> really shouldn't affect the rendering. IIRC,
> "&
--- "Greg A. Woods" <[EMAIL PROTECTED]> wrote:
> > Not only do tools not always follow these rules,
> you can't even always treat
> > HTML like that. Besides making a huge file, it
> messes up the rendering of
> > tables with sliced-up images.
>
> I'm not talking about placing blank lines and/or
[ On Monday, April 29, 2002 at 09:54:50 (-0400), Gary Bisaga wrote: ]
> Subject: RE: merge mode for XML
>
> >Doesn't everyone format their XML like that? I.e. like HTML so that
> >tags are on their own lines and there are extra blank lines (that won't
> >be
[ On Monday, April 29, 2002 at 07:23:03 (-0700), Noel Yap wrote: ]
> Subject: RE: merge mode for XML
>
> --- Sean Hager <[EMAIL PROTECTED]> wrote:
> > If CVS had away to use modular plug in "diff" and
> > "merge" programs, we could
> > setup a
Once again, take a look at message ID# [EMAIL PROTECTED]
posted to this forum on September 16, 2001. It illustrates one way (though
perhaps not the best way) to do just this. It relies on a lookup table that
looks up a diff tool given a file's name.
A better implementation would be to code a sy
--- Sean Hager <[EMAIL PROTECTED]> wrote:
> If CVS had away to use modular plug in "diff" and
> "merge" programs, we could
> setup a wrapper file that would automatically
> diff/merge the file
> differently based on the extension. e.g.:
>
> *.xml xml_dm
> *.htmlhtml_dm
Ideally,
>Doesn't everyone format their XML like that? I.e. like HTML so that
>tags are on their own lines and there are extra blank lines (that won't
>be treated as data) between groups of items and even between items too?
Not only do tools not always follow these rules, you can't even always treat
HTML
> A better approach is to avoid XML entirely in the first place
> -- it's a
> really really horrid syntax with all kinds of goo that's usually way
> over-kill for the application, being SGML based and all that
I agree that XML is overkill, but the truth is that it is here to stay.
XML is f
]]On Behalf Of
Greg A. Woods
Sent: 26. april 2002 23:45
To: CVS-II Discussion Mailing List
Subject: RE: merge mode for XML
A better approach is to avoid XML entirely in the first place -- it's a
really really horrid syntax with all kinds of goo that's usua
[ On Friday, April 26, 2002 at 08:16:44 (-0500), Sean Hager wrote: ]
> Subject: RE: merge mode for XML
>
> I am not a CVS expert, but I was thinking that perhaps the tags
> diff3 was looking for were different for xml. I am going to test it
> some more, prehaps I will have t
[ On Friday, April 26, 2002 at 06:51:36 (-0700), EXT-Corcoran, David wrote: ]
> Subject: RE: merge mode for XML
>
> It helps me to think of a plain ASCII text file source (C,java,perl etc) as
> a markup language where a newline is the only tag.
:-)
> To extend the delta gener
CTED]
> Subject: Re: merge mode for XML
>
>
> [ On Thursday, April 25, 2002 at 16:10:37 (-0500), Sean Hager wrote: ]
> > Subject: merge mode for XML
> >
> > Is there a merge mode or merge algorithm that works well
> for XML files?
>
> Doesn't diff3
D]]On Behalf Of
Sean Hager
Sent: Friday, April 26, 2002 9:17 AM
To: 'CVS-II Discussion Mailing List'
Subject: RE: merge mode for XML
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Thursday, Apri
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of
> Greg A. Woods
> Sent: Thursday, April 25, 2002 8:24 PM
> To: [EMAIL PROTECTED]
> Cc: CVS-II Discussion Mailing List
> Subject: Re: merge mode for XML
>
>
> [ On
[ On Thursday, April 25, 2002 at 16:10:37 (-0500), Sean Hager wrote: ]
> Subject: merge mode for XML
>
> Is there a merge mode or merge algorithm that works well for XML files?
Doesn't diff3 work well enough?
XML files are more or less just text, right?
If the tags are all on
Is there a merge mode or merge algorithm that works well for XML files?
Any experience here?
Sean.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
62 matches
Mail list logo
