RE: report on building CVS 1.11.2 on NT
> cvsnt status: reading from parapet: Socket operation on non-socket by the way, it says 'cvsnt' here because that what I called the executable. I am NOT using the cvsnt distribution, but just the standard CVS one. Kris ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tag locking change
Paul Sander writes: > > But the following streams of commands are exactly equivalent (assuming > rtag were modified to accept both -D and -r options): > > cvs checkout -r branch module cvs rtag -D now -r branch module > cvs tag label No, they're not, unless the module has no subdirectories. Like rtag now does again, checkout only locks one directory at a time, so commits can happen between directories just like they can with rtag. -Larry Jones In my opinion, we don't devote nearly enough scientific research to finding a cure for jerks. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is CVS usable for big companies/projects (HELP!!!)
On Wed, 9 Oct 2002, Ralph Jocham wrote: > Date: Wed, 9 Oct 2002 16:49:07 -0700 (PDT) > From: Ralph Jocham <[EMAIL PROTECTED]> > To: [EMAIL PROTECTED] > Subject: [info-cvs] Is CVS usable for big companies/projects (HELP!!!) > > Hi All, > I am trying to convince upper level management that > CVS is a good > choice as a version control system. Their main contra > argument is that > it does not scale. My argument would be that CVS is used by open source projects which provide mass *public* access to their repositories. That is one situation in which you need scalability; lots of customers coming in over the network to access your database. For in-house use, if scalability becomes an issue, it means you are doing something wrong, and your software project probably has bigger issues to worry about. Why do you need to worry about scalability? Probably because there are too many developers who put too much stuff into one single repository, and it has turned into a behemoth. Huge software needs to be divided into chunks to be manageable. Each chunk can have its own independent version control managed by the team responsible for that chunk, and that team can use its own repository. Look at the way a GNU/Linux distribution is put together. Someone working on a mail application does not put the kernel and glibc into his repository, and does not share the same repository with someone else working on an X window manager or compiler. These things are independently versioned, and their customers see only a high level, relevant view of the CM process: some version number for the entire component, having three integers separated by dots. In the end, you can say that the system is made up of these versions; you don't have to have some big repository in which you apply a single symbolic tag over every single piece of source code that goes into the OS distribution. So it's just not *useful* to be able to put a million source files into the same repository, and then worry whether a change to one of them breaks any of the 999,999 others. That's not going to scale no matter what, because the development tools and methods themselves won't scale to that. So it's completely irrelevant whether a version control system can handle it and how fast. What's relevant is whether it has the semantics so that you can practice useful CM on a component level. You want to work on your piece of the puzzle, and have stable, known versions of the other pieces you need to make your stuff run. Moreover, your stuff might have to run with several different versions of the other pieces; so it would be useless to be in the same repository and symbolically tag your stuff together with the other stuff. Imagine if, say, Mozilla and the GNU C Library shared the same repository. What good would that do? Okay, so you could apply a release tag to both of them at the same time. Great, so now all the users will have to upgrade their glibc together with their browser, because you only cared about developing them in combination, and have just one single combined configuration that works. But hey, your version control system *scaled* up to it, like the manager wanted after listening to the salesman from the proprietary version control company. That being said, some people claim to have good results for over a gigabyte sized CVS repositories. In my experience, CVS works okay for repositories that are at least a few hundred megabytes, under one big tree that is checked out by everyone. -- Meta-CVS: directory structure versioning; versioned symbolic links; versioned execute permission; versioned property lists; easy branching and merging and third party code tracking; all implemented over the standard CVS command line client -- http://freshmeat.net/projects/mcvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Is CVS usable for big companies/projects (HELP!!!)
Yes, and it does scale. You can have as many respositories as you need. Or even remote ones in different locations that mirror repositories at your present location. We switched from VSS to CVS for a few reasons. 1. its free. 2. it handles branching better. 3. unlike vss, cvs does not make copies of the files every time you change it, so it takes up a lot less disk space. I cannot even think of a company that would be to big for CVS. Good luck convincing them of this change. BTW, we use CVSNT here, as we don't have any Unix systems in house or in use. Thanks, Adam -Original Message- From: Ralph Jocham [mailto:[EMAIL PROTECTED]] Sent: Wednesday, October 09, 2002 4:49 PM To: [EMAIL PROTECTED] Subject: Is CVS usable for big companies/projects (HELP!!!) Hi All, I am trying to convince upper level management that CVS is a good choice as a version control system. Their main contra argument is that it does not scale. So, can you please give me some real world experiences on which big projects you used it. (Number of people, lines of code, distributed, ...) Also, names of well known companies CVS would help. (I think NASA is one, but I am not sure) With these numbers at hand I hope that I can convince them. Please reply ;) Thanks, Ralph __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ___ 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: Is CVS usable for big companies/projects (HELP!!!)
On Thu, 10 Oct 2002, Adam Braa wrote: > Date: Thu, 10 Oct 2002 09:59:22 -0700 > From: Adam Braa <[EMAIL PROTECTED]> > To: Ralph Jocham <[EMAIL PROTECTED]>, [EMAIL PROTECTED] > Subject: [info-cvs] RE: Is CVS usable for big companies/projects (HELP!!!) > > Yes, and it does scale. You can have as many respositories as you need. > Or even remote ones in different locations that mirror repositories at > your present location. Yes, and they can be on different machines, different networks, with different projects in them! That doesn't really address issues of scalability---anything scales under these condition. Scalability means that you have a lot of users over a lot of machines, but they all see a consistent view of One Big Thing, and it continues to perform well as more users are added. Of course, separation into little projects and repositories is the better way to do things. But someone who's been listening to some CM gospel from the vendors of a product that implements the ``one big repository for the world'' model might not see it that way, especially if they have already committed dollars in that direction. Repeating that gospel then justifies their decision. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tag locking change
>--- Forwarded mail from [EMAIL PROTECTED] >Paul Sander writes: >> >> But the following streams of commands are exactly equivalent (assuming >> rtag were modified to accept both -D and -r options): >> >> cvs checkout -r branch module cvs rtag -D now -r branch module >> cvs tag label >No, they're not, unless the module has no subdirectories. Like rtag now >does again, checkout only locks one directory at a time, so commits can >happen between directories just like they can with rtag. Yikes! So checkout is as reliable as rtag is with regard to the set of versions it affects. Okay, I amend the commands above as follows, noting that checkout would also need to be modified to accept both -r and -D options, recording only the branch in the Entries file: cvs checkout -D now -r branch module cvs rtag -D now -r branch module cvs tag label >--- End of forwarded message from [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Commit question
Is there a way to commit a change to a version without first having to check it out to your workstation? Thanks for any help. __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Checkout Error
I am trying to checkout module Projects/xub to my workstation. When I try, I get the following error... [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 [cvs] write stdout: Invalid argument [cvs] Write failed flushing stdout buffer. I believe I am getting the error, because I am checking out a two level module. After my job aborts, I look in file manager and I see the directory c:\checkout\Projects. However, I don't see any CVS directory. Therefore, when CVS tries to checkout the xub module underneath Projects, it fails. Is this a bug or am I doing something wrong? Any help is greatly appreciated. Thanks __ Do you Yahoo!? Faith Hill - Exclusive Performances, Videos & More http://faith.yahoo.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit question
Pat Young writes: > > Is there a way to commit a change to a version without > first having to check it out to your workstation? No. You could import it, but that probably isn't what you want. -Larry Jones Oh, now YOU'RE going to start in on me TOO, huh? -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout Error
Pat Young 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 > [cvs] write stdout: Invalid argument > [cvs] Write failed flushing stdout buffer. That looks like you're trying to checkout into an existing directory (Projects). Checkout really wants to create a new directory on checkout. -Larry Jones Kicking dust is the only part of this game we really like. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
On Fri, Aug 09, 2002 at 10:48:04AM -0700, Mike Ayers wrote: > >>I have to sync two CVS repositories located on two non- > >>connected networks. (yep, this means tape/CDROM transports, > >>I know it sounds silly). This was discussed a couple of months ago, and a few approaches were offered. Now we have to do the same thing. Not full synchronization, actually -- every revision, log message, and tag replicated. All we really need is that two sites be able to work on the same modules without stepping on each others' feet, and without being able to share a CVS repo. (We have to do it this way for political reasons, so digression into why we "shouldn't" have to, or technical suggestions on how to reduce it to a single repo, would NOT be helpful, i.e. I already know about ssh. I'm going to suggest BitKeeper, but I very much doubt they'll go for it. In short, I'm probably stuck with disconnected CVS, whether I like it or not. Bleah.) So I'm wondering whether anyone managed to turn that old thread into a concrete solution. If not, I'd appreciate comments on the approach I suggested back then -- actually a modification to something Paul Sander had described. Paul pointed out that my suggestion didn't meet the original poster's needs. True enough, and presumably because of that, no further discussion of it took place ... but it does appear to meet our, less stringent, needs; so a critique of it from that perspective would be helpful. Here's the original proposal: On Mon, 19 Aug 2002 11:47:15 -0700, I wrote: > On Fri, Aug 09, 2002 at 12:50:06PM -0700, Paul Sander wrote: > > Each site owns its own trunk. Each site creates a branch that is used for > > importing from the other site(s); these branches map to the trunk(s) at the > > remote site(s). No local commits are permitted on the import branches. > > Each site keeps a list of branches to export to the other site(s), and > > tracks the latest exported versions on each export branch. > > > > To send an update from a remote site, the latest exported versions table and > > the export branch table are consulted, and all versions that have never > > before been exported are packaged up and sent (and the tables are updated > > as needed). Tags are also sent out in an appropriate manner. > > > > To receive an update, the received versions are checked into the import > > branch(es) as needed, and the tags are translated accordingly. > > I just had an eeevil thought. You're gonna cringe, I know, but > bear with me :-) > > On system A, use a version of CVS which stores its metadata in > subdirectories called "CVS_A"; on System B, store the metadata in > "CVS_B". > > Now, on System A, CVS won't recognize System B's metadata; it'll > revision-control CVS_B/Entries etc. like any other files. And > vice versa. Thus, one should just be able to keep ping-ponging a > single sandbox back and forth between the two systems (via email, > FTP, sneaker-net, whatever), and each system will use its own > metadata to stash the new revisions in the right place. > > The systems in question had better have the same line-ending > conventions, of course... > > Does anyone know whether CVS can still withstand having CVSADM > and friends defined to different values, or has "CVS" gotten > hard-coded anywhere? (I know of one place; the ign_default > string in src/ignore.c. That'd have to have "CVS" removed, and > CVSADM added dynamically to the default ignore list.) And my answers to the criticisms Paul made at the time: - "I thought the idea here was to propogate version histories between multiple repositories, not to keep multiple sandboxes in synch. The method you propose does the latter..." As mentioned above, true, but in our case that's enough. I think. Are there reasons it isn't, that I'm not seeing? - "... and doesn't accomodate local changes to both sandboxes. It also provides no means to transfer other stuff such as RCS states and tags." Every resync involves getting a tarball from the remote site, importing it to the remote-site branch, and then merging from there to the trunk. That should handle local changes to both sandboxes. It should also handle the only RCS state I care about, i.e. "dead" :-) As I mentioned, I don't care about replicating tags. Thanks in advance. -- | | /\ |-_|/ > Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / The acronym for "the powers that be" differs by only one letter from that for "the pointy-haired boss". ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
On Thu, 10 Oct 2002, Eric Siegerman wrote: > Now we have to do the same thing. Not full synchronization, > actually -- every revision, log message, and tag replicated. All > we really need is that two sites be able to work on the same > modules without stepping on each others' feet, and without being > able to share a CVS repo. > > (We have to do it this way for political reasons, so digression > into why we "shouldn't" have to, or technical suggestions on how > to reduce it to a single repo, would NOT be helpful, i.e. I > already know about ssh. I'm going to suggest BitKeeper, but I > very much doubt they'll go for it. In short, I'm probably stuck > with disconnected CVS, whether I like it or not. Bleah.) In Meta-CVS, you can track third party code on any branch quite easily. This has nothing to do with CVS vendor branching; it is not based on the cvs import command. Here is the rundown: cd snapshot mcvs grab -r branch-name module-name # We now have a working copy checked out to branch-name. # The changes that will bring the snapshot into the branch look # like ordinary local edits that can be diffed, modified and # committed. mcvs ci # commit; third-party snapshot is now in the branch mcvs sw # switch to main trunk mcvs merge branch-name # merge the branch mcvs ci # commit, done I would give each time their own repository, and have them use a branch to track code snapshots from the other team. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: sync repositories
I have been working on a pair of Ant tasks that support merging code from N number of sub-development groups with their own source trees into the main branch of a cvs repository. How the remote sources are being stored is irrelevant to my custom Ant tasks. (In my case the other team is using the ENVY repository built into VAJ.) From an overall standpoint it is important that the entire ant build script has some way of obtaining the external source tree from each external sub-development group and updating each external sub-development group's SCM repository. I am more than happy to share the workload of developing the ant tasks with another developer outside my company. In fact I would like to submit the new tasks to the Jakarta project when they are complete. The vast majority of the work is already done but there is still several days of work to be done before the tasks are complete. Unfortunately I only have time to work on the tasks during short stints between iterations of the main project my group is working on. Be warned that writting custom ant tasks as well as understanding the tricky details of the problem that pop up is not for the faint of heart. Its not rocket science, but it is a bit tricky. I expect anyone new to the problem will take a day or more just to become aclimated to everything that is going on. Rather than regurgitate all the nasty details I ask that you browse the archives of the cvs (and cvsnt) user and ant development lists for my postings. They are all made under this email address:([EMAIL PROTECTED];[EMAIL PROTECTED]) or [EMAIL PROTECTED] If there is a better way to do all of this without writing custom ant tasks please let me know! James Lee Carpenter Software Engineer Household Technical Services 6602 Convoy Court San Diego, CA 92111 ph: 858-609-2461 email: [EMAIL PROTECTED] Eric Siegerman To: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]> <[EMAIL PROTECTED]>cc: Sent by:Subject: Re: sync repositories [EMAIL PROTECTED] g 10/10/2002 12:57 PM On Fri, Aug 09, 2002 at 10:48:04AM -0700, Mike Ayers wrote: > >>I have to sync two CVS repositories located on two non- > >>connected networks. (yep, this means tape/CDROM transports, > >>I know it sounds silly). This was discussed a couple of months ago, and a few approaches were offered. Now we have to do the same thing. Not full synchronization, actually -- every revision, log message, and tag replicated. All we really need is that two sites be able to work on the same modules without stepping on each others' feet, and without being able to share a CVS repo. (We have to do it this way for political reasons, so digression into why we "shouldn't" have to, or technical suggestions on how to reduce it to a single repo, would NOT be helpful, i.e. I already know about ssh. I'm going to suggest BitKeeper, but I very much doubt they'll go for it. In short, I'm probably stuck with disconnected CVS, whether I like it or not. Bleah.) So I'm wondering whether anyone managed to turn that old thread into a concrete solution. If not, I'd appreciate comments on the approach I suggested back then -- actually a modification to something Paul Sander had described. Paul pointed out that my suggestion didn't meet the original poster's needs. True enough, and presumably because of that, no further discussion of it took place ... but it does appear to meet our, less stringent, needs; so a critique of it from that perspective would be helpful. Here's the original prop
cvs diff on repository
I'm wanting to set CVS up so that every time a file is committed it will
send an email with the diffs to the other developers for code review.
I added a line to the loginfo file:
DEFAULT $CVSROOT/CVSROOT/cvsdiff.pl %{sVv}
cvsdiff.pl is a script that does a cvs diff of the two versions and
emails the results. However, a cvs diff does not work on the repository
files (",v"), it complains about missing CVS/Entries. Is there a way to
get the diff of two different versions of a file from the repository? I
noticed that the contrib/log.pl script is meant to be run from loginfo
and does a cvs status, which also fails for me from the repository.
Thanks for any help. I emailed a similar question yesterday before I
subscribed and got a reply saying that it's waiting for moderator
approval, so apologies if I end up posting this twice..
Aaron
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is CVS usable for big companies/projects (HELP!!!)
On Thu, Oct 10, 2002 at 09:59:22AM -0700, Adam Braa wrote: > Yes, and it does scale. You can have as many respositories as you need. Surely as the size of the repository and the number of developers increases, the chances of hitting the bugs described here recently go from rare to almost guaranteed. Matt ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Track importing of a project !
Hi , I m trying to get thru cvs adminstration. I want to know whether it is possible to put a hook for importing a project as we do it for commiting,using commitinfo. TIA. Bye and take care. -- Reply To : perl -e 'print pack "H*","756b5f6369407961686f6f2e636f6d";' OR to the above 'From' Address ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Is CVS usable for big companies/projects (HELP!!!)
>Hi All, >I am trying to convince upper level management that >CVS is a good >choice as a version control system. Their main contra >argument is that >it does not scale. >So, can you please give me some real world experiences >on which big >projects you used it. (Number of people, lines of >code, distributed, >...) >Also, names of well known companies CVS would help. (I >think NASA is one, but I am not sure) > >With these numbers at hand I hope that I can convince >them. > >Please reply ;) > You should have a look at: http://www.cvshome.org/cyclic/cvs/proj-comm.html Cyrille ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: report on building CVS 1.11.2 on NT
Thanks Larry, I guess that's somewhere in the manual. Sorry. so, on to the next problem :-/ First tests seem to say that it works, but I get an error message at the end of every cvs command D:\kris\temp\parapet\PPhead>cvsnt -t status Makefile -> main loop with CVSROOT=:server:parapet:/usr/local/cvsroot === File: Makefile Status: Up-to-date Working revision:1.10 Repository revision: 1.10/usr/local/cvsroot/parapet/PPhead/Makefile,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) cvsnt status: reading from parapet: Socket operation on non-socket -> Lock_Cleanup() Not sure that it matters though. Note that parapet is a Linux host (SuSE 6.3) running cvs 1.11.1p1 Kris > > Your rsh client is doing end-of-line conversions which screws up the CVS > client/server protocol. Just use the built-in :server: method instead > of the (default) :ext: method and it should work fine. > PS: sorry Mike, I didn't try your suggestion, but I'm sure it will work. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tag locking change
Hi Guys, sorry for butting in but I couldn't resist trying to add my 0,02 EUR... What I usually do in cases such as this, where there's a boundary between development and QA/approval, and where I am the admin, is this: Every development commit triggers an update of a separate working directory somewhere off the web server. After the update a deployment script is run which deploys the updated tree to the web server's document tree. During QA checking the working directory is locked to prevent any automatic updates (on the level of the auto-update script, not a CVS- level lock) so that everybody is quite clear on what it is exactly that QA is viewing. Then, if QA approves the working directory is tagged with an approval tag. Finally we do a CVS update to get all the commits that we missed while we were locked and the lock is removed so we have auto-updating after commits again. One of the things about this method is the decoupling of development and QA/testing CVS activity. To me, development and testing live in slightly different universes: development has different standards by which to measure the product than QA. So often you have development fixing bugs and implementing features at a slightly frantic pace whereas QA wants tighter control on what is tested when. So, another way of achieving that might be to have developers tag the tree whenever a bugfix or feature reaches stability, and QA update it's tree whenever a new tag is available. But that just means more work for everybody. Scripting can take away a lot of that work and tedium. Anyway, that's just my humble opinion. :) Erik --- Original mail from Adam Bregenzer --- On Wed, 2002-10-09 at 14:58, Greg A. Woods wrote: > [ On , October 9, 2002 at 14:26:15 (-0400), Adam Bregenzer wrote: ] > > Subject: Re: Tag locking change > > > > On Wed, 2002-10-09 at 13:58, Greg A. Woods wrote: > > > > > > Yes, sure, but that copying is done (or at least the source for the > > > copying is created with) "cvs update", RIGHT? (i.e. it had better be!) > > > > Not at all. The server that holds the cvs repository also has apache > > runing on it. When a commit occurs each file that is committed is > > copied into a seperate directory. That directory is the DocumentRoot > > for apache. That way, when a change is committed it is automagicall > > viewable by browsing to the cvs server. The point is that one who does > > not edit the site manages and approves the site. > > My point was that you can do the same thing more reliably with a "cvs > update" in a working directory that is the DocumentRoot. But then it wouldn't be automagic, it would be whenever cvs update is run. Certianly every minute would be 'acceptable' but this solution is fine. Plus in this case the repository and the live site have different directory structures. > > Currently that > > individual runs cvs rtag when the site is in a producation ready state. > > Then that individual _could_ edit the site, so it is irrelevant from the > access rights point of view whether or not that indivudual runs "cvs > tag" or "cvs rtag". He/she certianly *could* but do you want a manager knowing they can? :P Plus, she doesn't modify the code so why keep or have a checked out copy? (I understand it's necessary in cvs, I'm trying to make a point) > > Then a script is run that does a cvs export with that tag and posts it > > to the live site. It has nothing to do with the client, it's all > > *server* side. I see no reason for it to bve tied to an update, I don't > > even know how to execute a server-side script on update and wouldn't > > want to anyways. > > You could trigger the server-side "cvs update" in any number of ways, > though the very best would be if the individual doing the testing and > approving did it just before testing. It's primarially for the developers, the testers only see it at regularly scheduled intervals so a developer's commit doesn't fsck something up. The environment on the cvs server emulates the live environment, most developer machines do not that is the reason for the constant sync with cvs, immediate testing Plus, I don't want to give testers access to the test server and I don't want to write an interface for them to do it. > > > When it's "ready" you should be "cvs tag"ing the working directory which > > > matches the "ready" revisions of the files. > > > > But what if I have not working directory. What if the developers are > > just that. Developers. I can certianly tell them to tag it for me but > > that's a bit strange. > > That does not make any sense. You can have a working directory if you want. Well, the first sentence should be 'But what if I don't have a working directory', but I think you mean my point doesn't make sense. What if you don't want or need to have a working copy? You cannot really do anything in cvs without a working copy, which is obviously something some people on this list have not realized. The fact t
