Re: listing the modules
> "Dave" == Dave Smith <[EMAIL PROTECTED]> writes: Dave> Dave> r... r.. read the manual? manual? whats that? why thats almost Dave> genius! RTFM! wow! I would have NEVER thought of that .. the people Dave> that know you must be so proud .. to know someone who just cries out Dave> at a moments notice RTFM! everyone! lets all say it together .. say Dave> it loud and say it proud! RTFM! RTFM! RTFM! Dave> Dave> Dave> now thats over .. does anyone have any REAL advice on how they deal Dave> with the module file? has anyone written any scripts to automatically Dave> update the modules file? Let's see. In your previous posting (included below), you didn't ASK those questions. You asked "how do I create it" and "are there special things to put in it". Both of those questions are answered in the FM. If you didn't understand the FM, feedback upon what wasn't clear would be actually helpful. Dave> "Matt Riechers" <[EMAIL PROTECTED]> wrote in message Dave> news:[EMAIL PROTECTED]... >> Dave Smith wrote: >> > >> > so, how do I create that modules file? are there special things I should >> > place in it? >> > the modules file I have on the server has each module listed twice .. If I >> > remove one of the listings CVS gives me errors when I run 'cvs co -c' >> > >> > Dave >> >> http://www.cvshome.org/docs/manual/cvs_18.html#SEC157 >> >> -Matt >> Dave> Dave> ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update vs. checkout
AFAIK, you can only update a module that you've already checked out. So, you should only have to check out once (at the beginning) and update ever after. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Sendng updates to a directory
Well, let's see That was section C.7.2; section C.7.1 is about the "loginfo" file. Hmm. I wonder if the two are related somehow. In fact, as I look at section C.7, all is revealed, especially when you realize what section C is about. Did you even READ the documentation or simply expect us to spoon-feed you? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Your reply, as written, contradicts itself. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Making a file writeable
The problem is that you have multiple developers modifying the same area of code without communicating with each other. The way that you haven't solved that problem in the past is to not allow two developers to be able to modify the same source file at the same time. That costs you time when the areas of code that the developers are modifying are non-overlapping (two different methods of the same class, for example). Since you don't seem to be complaining about your inability to do *that*, I guess that your management is unable to divide the work in such a fashion or your code is so spaghetti-like that you *cannot* divide your work in such a fashion. It seems that you should find a source control tool that acts the way that you wish. That tool isn't CVS. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - setup reserved checkout
Conflicts are easy to produce *when you have multiple developers working on the same segments of code*. If you are doing a lot of that without any coordination between the developers, you are going to have a lot of problems. Period. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: question about cvsignore
My local respository is in /usr/local/cvsroot. I went into my working area and issued... cvs -d /usr/local/cvsroot/ co CVSROOT ... I then changed into the new working area subdirectory of CVSROOT and issued... echo "*.class *.txt *.jar" > cvsignore cvs add cvsignore cvs commit -m "New file" cvsignore ...and things are added into the repository as expected. Does that help? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: need help with binaries
In fairness to the original poster, I probably would not wish to read a manual written in a foreign language. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Converting ClearCase to CVS
Out of curiosity, why are you moving from ClearCase to CVS? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Hierarchical team integration in CVS
>From his description, I suspect that this is a Java project. Each package *will* be in its own directory in that case. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Converting ClearCase to CVS
Oh yes. I've felt that the return that we get from CC around here is not worth what we are paying for it. I'm not high enough in the food chain to change things. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: refactoring when using CVS
Refactoring in C or C++ is child's play in CVS. In almost all cases, you don't have to move things into a different directory. In Java, a refactoring into a different package practically forces a move into another directory. That's a real PITA with CVS; while that may be my problem rather than CVS's, it would entice me to find a tool that makes it less of a problem for me. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Reflecting changes with cvs import
> "EB" == E B <[EMAIL PROTECTED]> writes: EB> EB> Why doesnt cvs import 'remove' files when it can EB> 'add' files? You *are* joking aren't you? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: refactoring when using CVS
> "David" == Thornley, David <[EMAIL PROTECTED]> writes: David> >> -Original Message- >> From: Noel Yap [mailto:[EMAIL PROTECTED]] >> > Refactoring in C could just as easily leave you with >> > a whole lot of >> > deleted files and a whole lot of new files. >> >> The difference is that as a language, C doesn't demand >> such changes (ie renames and moves), while Java does. >> David> Yup. In that respect, I consider Java broken. Well, to be absolutely picky Java really *doesn't* care where the source files reside. In fact, there doesn't have to be any correlation between the source file name and the resulting .class files. It simply makes finding things in the Java source difficult; it also would not allow you to do incremental compilation or even figure out the dependencies. If you have all of your source in one big pile, you can do a "javac *.java" and things should sort themselves out. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: refactoring when using CVS
> "Paul" == Paul Sander <[EMAIL PROTECTED]> writes: Paul> Paul> Unfortunately, if this is what your build procedure consists of, Don't be silly. We have our own make tool (written in Java in fact) that enforces various packaging layers during designer compilation and loadbuild. Paul> then you lose traceability between your sources and shippables, and Paul> you can't assess the impact of any change you make to your source Paul> code. That makes it really really hard to accomplish the common task Paul> of shipping minimal patches when bugs are found in the product. I believe that you would be insane to handle Java source in the fashion described in my previous posting. My point was, however, that the language does not *force* you to keep the source in some sort of coherent order so that it's incorrect for people (including me) to claim that it does. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: refactoring when using CVS
Of course, from your very own web page you state... However I have so far resisted any temptation to learn anything significant about any of the bastardised half-breed languages such as C++, Perl, etc., or even most of their ill-begotten offspring such as Java, C#, etc. ...so it doesn't surprise me very much that you have such a uninformed opinion on the matter. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: OT: C++, yuck!
> "Thomas" == Thomas S Urban <[EMAIL PROTECTED]> writes: Thomas> Thomas> On Wed, Feb 27, 2002 at 12:59:48 -0500, Greg A. Woods sent 2.8K bytes: >> "dynamic binding" isn't a feature you could ever possibly decide on >> needing up front for any kind of project you'd ever even get close to >> justifying C for! Get real! Thomas> Thomas> You're wrong. Read what I wrote again. Projects I am working on satisfy Thomas> the description I gave. Then again, I'm not real, but I'm working on Thomas> it. In this case, he's correct. After all, if you need dynamic binding, then you can't use C and therefore can't justify using it for said project. :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: OT: well bred language [was RE: refactoring when using CVS]
Ruby? With the Perlish syntactic trash like... "It uses simple naming conventions to denote the scope of variables. Examples: simple 'var' = local variable, '@var' = instance variable, '$var' = global variable. So it is also not necessary to use a tiresome 'self.' prepended to every instance member." ...? No thanks. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: renames under CVS
> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes: Noel> Noel> Also, search tools will be useless if this programmer were Noel> programming in Java since the class names would be as meaningless as Noel> the filenames. I suppose he then could start relying heavily on Noel> comments. There is no requirement for the source file name to be remotely related to the name of the class(es) contained within it. There *is* convention and it *does* make life easier when you do so, but it is *not* a requirement. jtags will work in either environment. I assume that the OP who has the C function jumble uses something along the lines of cscope anyways. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
OT: Java filenames and classes
>>>>> "Noel" == Noel Yap <[EMAIL PROTECTED]> writes:
Noel>
Noel> The following output suggests otherwise:
Noel>
Noel> nyap:jpmpsdev@EQUINOX:~/proj/asdf> cat Asdf.java
Noel> public class Aoeu
Noel> {
Noel> public static void main(String[] args)
Noel> {
Noel> System.out.println("Yo");
Noel> }
Noel> }
Noel> nyap:jpmpsdev@EQUINOX:~/proj/asdf> javac -classpath .
Noel> Asdf.java
Noel> Asdf.java:1: class Aoeu is public, should be declared
Noel> in a file named Aoeu.java
Noel> public class Aoeu
Noel>^
Noel> 1 error
Noel>
Noel> Am I missing something here? Is there a flag to make
Noel> this error into a warning?
Noel>
Noel> If there isn't, I think the "should" in the warning
Noel> should be changed to "must".
I sit partially corrected.
A public class must sit in a file that matches the classname. A package
level class does not. The directory where the source resides does not have
to match in any fashion the package statement included in the source file.
FWIW, in java 1.2.2 the error message contained "...must be defined in a
file..."
So yes, you cannot willy-nilly stick all of your java source in files whose
names have no connection to the classes defined within. You can, however,
do so with package level classes. You can also place all of those files in
any directory structure that you wish; however any autodependency stuff
will not work in that case.
--
Mark A. Flacy Architect Weasel CS3K Solution OAM&P, Group B824
[EMAIL PROTECTED] (972) 685-8347 (ESN) 445-8347
Any opinions expressed above are my own. Any facts expressed above
that you could detect means my weasel wording needs work.
"Engineering is the art of making what you want from things you can get."
--Unknown
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: OT: Java filenames and classes
You are repeating the first scenario; there is nothing new here. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and Jar files: Should you import Jar into the Repository? Why or why not
> "Richard" == Richard Caley <[EMAIL PROTECTED]> writes: Richard> Richard> In article <[EMAIL PROTECTED]>, Greg A Woods (gaw) writes: gaw> With CVS and non-diff-able, non-patch-able files we're talking about gaw> using a tool that's not even remotely suitable for the job at gaw> hand. Richard> Richard> Lets be concrete. Richard> Richard> Say I have a software project consisteing of some number of Richard> directories with text files in it. I keep this in CVS because I Richard> want version tracking. Richard> Richard> Now, someone comes along and tells me every software project needs Richard> an icon, so this here GIF has to be part of the build. Obviously I Richard> need to version control it in sync with the source to be able to Richard> build old versions. No, you need to keep track of the version of the icon used when you hit certain release points of your software. Do you change the icon often during development? Are those intermediate versions of the icon worthy of checkpointing? Richard> Solution 1 is to set up some other versioning system (software or Richard> ad-hoc) to version control the image file. This gains me nothing and Richard> costs me support overhead and possible errors compared to solution 2. Richard> Richard> Solution 2 is to check the GIF file into CVS. This gains me simplicity Richard> and reliability and loses me nothing compared to solution 1. I can't Richard> diff the versions of the GIF anyway, so the fact that CVS won't add Richard> this ability is not an issue. Solution 3 is to maintain the binary image files in another directory on your repository machine. Add steps to your loadbuild scripts (which should be version controlled) to fetch the correct image and install it to the correct place. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS, SSH, (Light) Security
> "Richard" == Richard Caley <[EMAIL PROTECTED]> writes: Richard> Richard> I would like to give some people read only access. Preferrably only to Richard> some modules. Richard> Richard> CVS provides no support, as it does for pserver. Richard> Richard> I can't, so far as I can see, use file permissions, users need write Richard> acess to the repository to make lockfiles etc all over the place. That's not the same as giving them write permission on the individual files. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: english text only?
List? What list? I'm reading this in the newsgroup gnu.cvs.help. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Forcing commit for a group of files
If it hasn't changed, why do you wish to act as if it has? Is this related to the use of CVS internal version numbers? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: english text only?
> "Greg" == Greg A Woods <[EMAIL PROTECTED]> writes: Greg> Greg> Count me out. I don't do news much any more -- e-mail is far easier for Greg> me to handle. I'll stay on the list and continue to campaign for Greg> subscriber-only access (which will at least kill half the spam or more). (dons NOMEX outfit) Reads as if you are using poor tools for your news reader. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: lock-modify-unlock model and cvs admin -l
> "John" == John Lippiello <[EMAIL PROTECTED]> writes: John> John> Hi John> My company uses the lock-modify-unlock model of software John> development. OK. John> We are considering moving to CVS. OK. That rather implies that you are not going to do the first sentence any more. John> I see in the Cederqvist document in Sec. A.6.1 that there is a way to John> lock using "cvs admin -l". At the start of section A.6 is a comment John> that some of the options in this section have questionable usefulness John> and may be removed. Does anyone know if the "cvs admin -l" is John> classified as having questionable usefulness. Why would you want to use a concurrent version control system in a non-concurrent fashion? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: where is inetd.conf?
Linux 6.2? What is that? The kernel's only up to the 2.5.x... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: newbie question
"info cvs" Look for "Starting a new project". (http://www.cvshome.org/docs/manual/cvs_3.html#SEC38 gives the same information) It appears that you should also look at http://www.cvshome.org/docs/manual/cvs_2.html#SEC31 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: arch
Yep. The site has been down for about a week now. (http://www.regexps.com/) I haven't done much with it yet. It seems powerful, but somewhat confusing to use; I think that's a direct function of not having done much with it. :-) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: arch
To be precise, arch (larch, really) has had a presence. In fact, the developer is already "eating his own dog food" and has the larch repo available under larch. I think that he's merely upgrading his apache server. What I downloaded is most certainly not vaporware. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge mode for XML
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
Re: ant and cvs directory structure?
What do you mean by a project? I don't understand your setup. Why wouldn't you simply keep cvsroot/jroot/com/foo/product1/bar product2/baz tayek/product1 org/quux/product1 directory structure? (Which above won't make sense unless you look at it with a monospace font.) If you don't want all of the subdirectories to be checked out, create some modules to allow you to pick and choose. (I also think that ant is the wrong solution to compiling java source, but that's extremely OT for this newsgroup.) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Vendor branches and head revisions
Why not simply add an empty comment to each file in the trunk at the very beginning? That way they are all modified. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem when using shell script to checkout huge binary files (>70MB)
It probably *is* a java problem. The java run time process starts up with a given amount of heap space. Try adding a -Xmx128m to the java command line to see if that makes a difference. java -X will give you all of those non-standard options. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
