Re: Refreshing my working directory
Danial Islam writes: > > How can I refresh the whole directory instead of getting all the files > merged? I can't use "cvs update -C" because I have version 1.10, which > doesn't implement it, and it is a hassle for everyone else to upgrade to > version 1.11.1. 1.10 and 1.11.1 are compatible, so feel free to upgrade yourself without making anyone else do the same. Without -C, you need to delete the locally modified files and then update. It might be easier to delete your working directory and do a new checkout. -Larry Jones My brain is trying to kill me. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Refreshing my working directory
Hi, I have a working directory called TempDir. Recently the files in the repository were modified, so I want to do a refresh of my whole working directory, even the files that I changed in my working directory and have not checked in yet. I want everything in TempDir to be updated with the latest files and overwritten. However, when I run a "cvs co TempDir", it just *merges* my modified files with the latest files instead of overwriting (refreshing) them. Similarly, if i do a "cvs update" from the topmost directory, it does the same thing. How can I refresh the whole directory instead of getting all the files merged? I can't use "cvs update -C" because I have version 1.10, which doesn't implement it, and it is a hassle for everyone else to upgrade to version 1.11.1. Danial. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
I might just sit back and watch the show, but I like to be part of the
fun ;)
DTDs are certainly not enough in a lot of situations, and XML Schemas,
RELAX NG, or what-have-you won't ever obliviate the need for documentation
and project management.
But sometimes, well-formed XML is worthy of version management even
when no-one bothers about a schema. For example, you might need to save
some of those short-lived XML-formatted messages for a regression test.
Also, there is now a trend towards a more Unix-like 'tool-set' approach,
in which different parts of a chain of processes are responsible for
different tasks. While it might be valuable early in a proces to validate
an XML instance, it might be a waste of resources later in the proces.
There's also another interesting trend: HyTime is slowly being re-invented
in XML incarnation. Which to me is proof-of-concept: you can dream up
another syntax (and a full-blown SGML parser might even be able to parse
it, given a suitable SGML declaration), but in the end, it doesn't make
much of a difference whether you write something or
(concept something) or \concept{something} or whatever; the fundamental
issue is the same: You are not really supposed to look at the markup
except as an expression of structure.
Which was what started this thread: how to diff and merge in a meaningful
way, i.e. in a way that knows that isn't
different from in a way that most XML
applications should care about. You can come this far with just well-formed
XML. When it comes to whitespace in character context, things get really
interesting. XML in essence leaves it up to the application what to do with
whitespace, so you have to know the application in order to decide whether
a whitespace difference matter. A DTD or schema helps a lot because you
can then ignore whitespace in element context.
BTW, I stumbled over yet another XML diff, this one written by
Norman Walsh:
http://nwalsh.com/java/diffmk/
and a small feature about whitespace and prettyprinting XML:
http://www.xml.com/pub/a/2002/01/02/whitespace.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 that you ought
to write DTDs or schemas (just yesterday I had to make one of our developers
do so, and our own internal XML infrastructure requires them). But to call
documents without DTDs/schemas "not XML" and unworthy of configuration
management is certainly not supported by the XML spec or common usage. For
one thing, as I'm sure you know, the XML spec does not seem to deprecate
well-formed XML documents. When I was in the W3 XML working group (1999)
there was certainly a group of us (not everybody) who believed that
well-formed documents had a place in the world.
And if we take this tack, what about constructs not declarable with DTDs?
XML Schemas will certainly improve this, but many people are not using them
yet. Are DTDs with "ANY" declarations also not XML, since they really don't
describe the semantics of the document? Since DTDs can't describe data types
or other restrictions (such as field length), is any DTD'ed document "not
XML"?
DTDs and schemas are good and should be used wherever possible. But 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
Subject: RE: merge mode for XML
> There's a class of simple XML documents that live and
> die without getting near either a DTD or revision control.
> Without a schema and accompanying documentation, there's no
> way to tell the semantics of the XML document, and not much
> point in version management.
Amen. I couldn't agree more!
Those who dare call such things "XML" are sadly mistaken.
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
On Wed, 1 May 2002 [EMAIL PROTECTED] wrote:
> > I have made a mistake in accessing the host: I used
> >
> > :pserver:cvs@localhost:/home/cvs/repository
> >
> > and wanted to use
> >
> > :pserver:[EMAIL PROTECTED]:/home/cvs/repository
> >
> > Is it dangerous to do this? I do not have other files called Root.
> > I do not want to redownload everything from remote (the problem is: I
> > used this tree locally and burned it to a CDR).
> >
> > find -type f -name 'Root' \
> > -exec perl -pi -e 's/localhost/some.hostname/g' {} \;
I use a variant:
find . -type f -name 'Root' | \
xargs perl -pi.bak -e 's/localhost/some.hostname/'
This tends to launch perl only once or twice, depending upon the
size of the tree, thanks to xargs.
I prefer using perl rather than a 'cp' because some of our modules
are nested and I don't trust the Root file to be identical all
through the tree. Maybe they are, maybe they aren't.
It also makes it easier to repair damage should some foolish programmer
have a file named 'Root' with other content.
--
Joi EllisSoftware Engineer
Aravox Technologies [EMAIL PROTECTED], [EMAIL PROTECTED]
No matter what we think of Linux versus FreeBSD, etc., the one thing I
really like about Linux is that it has Microsoft worried. Anything
that kicks a monopoly in the pants has got to be good for something.
- Chris Johnson
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: determining versions on checkin
> I have a post proccessing script called from loginfo > that records audit information, including the version and > branch just checked in. > It parses the CVS/Entries file in the checked out sandbox > to get the version. > > The problem I'm having is that I'd like to use remote cvs, and > so accessing the CVS/Entries file is no longer feasible. > I'm looking for suggestions about other ways to capture > the version of a file just checked in. > You should be able to pass that into a loginfo script as an argument by specifying %v. It won't tell you what the branch is, but you should be able to figure that out from the revision number. David H. Thornley| If you want my opinion, ask. [EMAIL PROTECTED] | If you don't, flee. http://www.thornley.net/~thornley/david/ | O- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
determining versions on checkin
I have a post proccessing script called from loginfo that records audit information, including the version and branch just checked in. It parses the CVS/Entries file in the checked out sandbox to get the version. The problem I'm having is that I'd like to use remote cvs, and so accessing the CVS/Entries file is no longer feasible. I'm looking for suggestions about other ways to capture the version of a file just checked in. thanks dave -- Dave Uebele[EMAIL PROTECTED]360-876-4587 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: #cvs.lock error in Emptydir
Arcin Bozkurt writes: > > cvs server: Updating . > cvs server: failed to create lock directory for > `/opt/cvsroot/CVSROOT/Emptydir' > (/opt/cvsroot/CVSROOT/Emptydir/#cvs.lock): > Permission denied You need to change the permissions on /opt/cvsroot/CVSROOT/Emptydir so that everyone can write to it. -Larry Jones I don't need to do a better job. I need better P.R. on the job I DO. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout Problem
Cornellious Mann writes: > > [cvs] cvs checkout: in directory Projects: > [cvs] cvs checkout: cannot open CVS/Entries for > reading: No such file or directory > [cvs] cvs checkout: cannot open CVS/Tag: No such file > or directory > [cvs] cvs [checkout aborted]: cannot open > CVS/Entries.Static: No such file or directory That looks suspiciously like you're trying to checkout into an existing directory rather than letting checkout create a new directory. -Larry Jones Yep, we'd probably be dead by now if it wasn't for Twinkies. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving CVS repository
> I have made a mistake in accessing the host: I used
>
> :pserver:cvs@localhost:/home/cvs/repository
>
> and wanted to use
>
> :pserver:[EMAIL PROTECTED]:/home/cvs/repository
>
> Is it dangerous to do this? I do not have other files called Root.
> I do not want to redownload everything from remote (the problem is: I
> used this tree locally and burned it to a CDR).
>
> find -type f -name 'Root' \
> -exec perl -pi -e 's/localhost/some.hostname/g' {} \;
The last time I had to do a similar thing I had people create a file
called CVSRoot in their home directories and run
find -type -f -name 'Root' \
-exec cp /home/whoever/CVSRoot {} \;
Perl just looks like overkill here.
I had no problems.
David H. Thornley| If you want my opinion, ask.
[EMAIL PROTECTED] | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
[ 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 schema. You guys are just re-iterating all the silly arguments that have come and gone with EDI. New face, same old problem. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: merge mode for XML
[ 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 own internal XML infrastructure requires them). But to call > documents without DTDs/schemas "not XML" and unworthy of configuration > management is certainly not supported by the XML spec or common usage. For > one thing, as I'm sure you know, the XML spec does not seem to deprecate > well-formed XML documents. When I was in the W3 XML working group (1999) > there was certainly a group of us (not everybody) who believed that > well-formed documents had a place in the world. Just because some stupid ill-advised practice is common doesn't mean it should be condoned. Specification committees are, by their very nature, political creatures. Those of you who practice such "shady" techniques are able to sway a political process, but that doesn't mean what you do is "right". In any case, what do you mean by "ought to"!?!?!?!? SGML syntax is not self-documenting by and of itself. Do you build relational databases without defining a schema? Do you design data structures which have the sole purpose of interchanging data between published APIs but that are not documented? "well formed" by definition should mean in conformance to a pre-existing DTD! As has been mentioned already, no XML parser worth its salt can even begin to interpret an XML document without first reading the DTD that describes it! What do you do, parse your XML documents by hand? Finally let's also note that if you are using loosely defined XML-like formats for data interchange between programs then presumably you are careful enough only to do so in contexts where the content is highly dynamic (i.e. not static and long lived), in which case it certainly isn't suitable for CVS, if indeed any form of change tracking > And if we take this tack, what about constructs not declarable with DTDs? > XML Schemas will certainly improve this, but many people are not using them > yet. Are DTDs with "ANY" declarations also not XML, since they really don't > describe the semantics of the document? Since DTDs can't describe data types > or other restrictions (such as field length), is any DTD'ed document "not > XML"? What about them? XML is no more a final all-encompassing solution than the entire SGML framework from which it comes! Do all your tools look exactly like hammers? This is yet another situation where you must learn to use the right tool for the job! > DTDs and schemas are good and should be used wherever possible. But there > are realities of life. Indeed, and in the reality you're existing in you are defining overly complex little languages which you then mis-name as XML. -- Greg A. Woods +1 416 218-0098; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Planix, Inc. <[EMAIL PROTECTED]>; VE3TCP; Secrets of the Weird <[EMAIL PROTECTED]> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Errors during Import
Hi All, I have just imported a huge directory structure into cvs repository. of nearly 2GB database. However i got errors for some files during import. I have imported the directory structure using WinCvs to cvs_repository on Solaris. 1) Error: File has the wrong line feed for this machine For some other file the error was 2) Error: File has some escape characters in it ( 0x00.0x20,0x... What should i do to avoid these errors. Please reply. Thanks and Regards iqbal
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 schema. <>< gary -Original Message- From: Noel Yap [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 01, 2002 11: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 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 own internal XML infrastructure > requires them). But to call > documents without DTDs/schemas "not XML" and > unworthy of configuration > management is certainly not supported by the XML > spec or common usage. For > one thing, as I'm sure you know, the XML spec does > not seem to deprecate > well-formed XML documents. When I was in the W3 XML > working group (1999) > there was certainly a group of us (not everybody) > who believed that > well-formed documents had a place in the world. > > And if we take this tack, what about constructs not > declarable with DTDs? > XML Schemas will certainly improve this, but many > people are not using them > yet. Are DTDs with "ANY" declarations also not XML, > since they really don't > describe the semantics of the document? Since DTDs > can't describe data types > or other restrictions (such as field length), is any > DTD'ed document "not > XML"? > > DTDs and schemas are good and should be used > wherever possible. But 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 > Subject: RE: merge mode for XML > > There's a class of simple XML documents that > live and > > die without getting near either a DTD or revision > control. > > Without a schema and accompanying documentation, > there's no > > way to tell the semantics of the XML document, and > not much > > point in version management. > > Amen. I couldn't agree more! > Those who dare call such things "XML" are sadly > mistaken. > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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 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 own internal XML infrastructure > requires them). But to call > documents without DTDs/schemas "not XML" and > unworthy of configuration > management is certainly not supported by the XML > spec or common usage. For > one thing, as I'm sure you know, the XML spec does > not seem to deprecate > well-formed XML documents. When I was in the W3 XML > working group (1999) > there was certainly a group of us (not everybody) > who believed that > well-formed documents had a place in the world. > > And if we take this tack, what about constructs not > declarable with DTDs? > XML Schemas will certainly improve this, but many > people are not using them > yet. Are DTDs with "ANY" declarations also not XML, > since they really don't > describe the semantics of the document? Since DTDs > can't describe data types > or other restrictions (such as field length), is any > DTD'ed document "not > XML"? > > DTDs and schemas are good and should be used > wherever possible. But 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 > Subject: RE: merge mode for XML > > There's a class of simple XML documents that > live and > > die without getting near either a DTD or revision > control. > > Without a schema and accompanying documentation, > there's no > > way to tell the semantics of the XML document, and > not much > > point in version management. > > Amen. I couldn't agree more! > Those who dare call such things "XML" are sadly > mistaken. > > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs __ Do You Yahoo!? Yahoo! Health - your guide to health and wellness http://health.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
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 own internal XML infrastructure requires them). But to call documents without DTDs/schemas "not XML" and unworthy of configuration management is certainly not supported by the XML spec or common usage. For one thing, as I'm sure you know, the XML spec does not seem to deprecate well-formed XML documents. When I was in the W3 XML working group (1999) there was certainly a group of us (not everybody) who believed that well-formed documents had a place in the world. And if we take this tack, what about constructs not declarable with DTDs? XML Schemas will certainly improve this, but many people are not using them yet. Are DTDs with "ANY" declarations also not XML, since they really don't describe the semantics of the document? Since DTDs can't describe data types or other restrictions (such as field length), is any DTD'ed document "not XML"? DTDs and schemas are good and should be used wherever possible. But 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 Subject: RE: merge mode for XML > There's a class of simple XML documents that live and > die without getting near either a DTD or revision control. > Without a schema and accompanying documentation, there's no > way to tell the semantics of the XML document, and not much > point in version management. Amen. I couldn't agree more! Those who dare call such things "XML" are sadly mistaken. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: #cvs.lock error in Emptydir
I had this problem before. I think you have to set write permissions (e.g. chmod -R o+w *) on the directories you want to checkout. They're probably set to read-only now. Danial. Arcin Bozkurt wrote: > This is what I get when doing an update: > > cvs server: Updating . > cvs server: failed to create lock directory for > `/opt/cvsroot/CVSROOT/Emptydir' > (/opt/cvsroot/CVSROOT/Emptydir/#cvs.lock): > Permission denied > cvs server: failed to obtain dir lock in repository > `/opt/cvsroot/CVSROOT/Emptydir' > cvs [server aborted]: read lock failed - giving up > > What can I do to solve it? > > Thanks. > > -arcin > > ___ > Info-cvs mailing list > [EMAIL PROTECTED] > http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
