One Workspace, Multiple Repositories
Consider the following scenario: I have a workspace on the local disk of my PC here at work. I like working from the local disk because it's fast. I have a personal repository on a networked filesystem. At the end of each day, I update the repository. Among other things, this serves as a backup, and it also makes it easy to work from home if I want to. Periodically, say once a week, I'd like to check my code into a separate, official departmental repository. And, when changes are made in the departmental repository, I'd like to be able to cvs update the changes to my workspace (and check them into my personal repository as well). Back in October, there was some talk of patching cvs to provide the one workspace, multiple repository functionality I'm looking for: http://mail.gnu.org/archive/html/info-cvs/2002-10/msg00429.html Did anything ever become of this? Thanks! -David +--+ David Eisner| E-mail: [EMAIL PROTECTED] | CALCE EPSC | Phone: 301-405-5341 | University of Maryland | Fax:301-314-9269 | +--+ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and multiple platforms - version conflicts, features available etc.
On Tuesday 07 January 2003 07:16 pm, ADFH wrote: Basically in this situation there are management, programmers and graphic designers. In specific project at present, programmers using JSP and Java and tweaking some of the HTML. The graphic designers use DreamWeaver.. Problems arise on occasion when programmers edit inside templated areas of HTML files and then graphic designers push out a change to templates. I don't know anything about DreamWeaver, but I've seen lots of other templating systems over the years, and they've always had some relatively-easy-to-recognize technique for separating template-text from everything else. Assuming that's the case for DreamWeaver, you could write a commitinfo hook that checked the file being committed for changes *inside* the template area and disallow the commit if any are found. That would leave the programmer with a file he couldn't check in, but that's sort of the idea after all :-) -- Ross A. Patterson Chief Technology Officer CatchFIRE Systems, Inc. 5885 Trinity Parkway, Suite 220 Centreville, VA 20120 (703) 563-4164 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How is a patch applied to CVS?
Q On Mon, Jan 06, 2003 at 08:23:52PM -0500, Mazza, Glen R., ,CPMS wrote: How is a patch file committed into CVS to update the most recent version? In several steps: - Apply the patch to a checked-out working directory - Resolve any conflicts (i.e. .rej files) - Compile and test - cvs commit CVS itself can't digest arbitrary patch files. /Q Thanks, Eric (and others who answered)--I'm mostly from the Windows environment and I didn't know about the UNIX patch utility to work with patch files. Glen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: One Workspace, Multiple Repositories
:Consider the following scenario: : :I have a workspace on the local disk of my PC here at work. I like :working from the local disk because it's fast. I have a personal :repository on a networked filesystem. At the end of each day, :I update the repository. Among other things, this serves as a backup, :and it also makes it easy to work from home if I want to. I think cvsup is what you need, isn't it? I gave it a try a while ago when I was working on some project. I had to keep two CVS repositories up to date in different machines. So i used cvsup which synchronizes the cvs repository in host geek.com, for, instance with that in geekier.com. http://www.cvsup.org/ sherzod ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tagging files
Hi all, AFAIK In CVS all users's log entries goes to history files in CVSROOT but I want that although users can add to history but they should not be able to tag the files as in my case All the users are able to tag the files but I need Admin can tag the code and other Admin stuff like Branching etc as well and not all users The logging is usually done by the default loginfo functionality. I don't believe the log entries go into the history file. (It isn't in mine.) Why don't you look into taginfo? You can check who is doing the tags and abort the tag if it isn't authorized. P.S.: If i make the history file read only then users can't log history to history file. Exactly what is this going to accomplish? If you want to prevent the history from being logged, then (a) remove any file named history from CVSROOT and (b) check all the *info files in CVSROOT to make sure they aren't logging anything. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: One Workspace, Multiple Repositories
On Thu, Jan 09, 2003, David Eisner wrote: Consider the following scenario: I have a workspace on the local disk of my PC here at work. I like working from the local disk because it's fast. I have a personal repository on a networked filesystem. At the end of each day, I update the repository. Among other things, this serves as a backup, and it also makes it easy to work from home if I want to. Periodically, say once a week, I'd like to check my code into a separate, official departmental repository. And, when changes are made in the departmental repository, I'd like to be able to cvs update the changes to my workspace (and check them into my personal repository as well). Although a slightly different approach, but perhaps also useful for your situation: my RSE CVS patchset (see http://mail.gnu.org/archive/html/info-cvs/2002-12/msg00358.html) contains a cvs root command plus the ability that CVS on-the-fly switches CVSROOT between a read-only local copy of the repository (for fast/offline working) and an original remote repository (for central storage). This works by making a local copy of the repository (via rsync over ssh by default) after every repository WRITE operation (cvs commit, cvs tag, etc) and by diverting all READ operations (cvs diff, cvs update, etc) to the local repository. As an example: the OpenSSL CVS repository is at $CVSROOT == cvs.openssl.org:/e/openssl/cvs. to which a developer has access via CVS over SSH. With my RSE CVS patchset applied, you now can do: $ cvs root -e openssl cvs.openssl.org:/e/openssl/cvs \ /u/rse/cvs/openssl rsync:!.#*,!CVSROOT/commitlogs/ This just remembers in $HOME/.cvsroot that the repository (arbitrary) named openssl has a master location under the remote path cvs.openssl.org:/e/openssl/cvs and a slave location under the local path /u/rse/cvs/openssl. And that the local reposistory can be updated via rsync (and that some files are excluded for speed reasons). To establish the local repository copy once initially you just run $ cvs root -s openssl This performs the rsync operation. Now you can check out your working files from the repository: $ cvs -d openssl co openssl-src Keep in mind that you just specify a logical name for the repository (which in stock CVS is invalid). This automatically checks out with high speed from the local copy. Now you can do all your work, e.g.: $ cd openssl-src $ vi CHANGES $ cvs diff CHANGES etc. To merge in the changes of other developers you just run: $ cvs root -s ossp $ cvs update This first brings your local repository up-to-date, then updates from there. If you now commit or tag something, CVS automatically temporarily switches to the master (remote) repository, immediately followed by an implicit cvs root -s openssl operation to immediately bring your local repository up-to-date again. I've originally implemented this two years ago for use with the ASF's Apache CVS repository and my Laptop and using it since this time on a daily basis with the OpenSSL, OpenPKG and OSSP projects. The nice thing is that you do not have to change the ways you are used to work with CVS and still get the advantage to work fully offline with high speed. Yours, Ralf S. Engelschall [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Change history?
hi Is there anyway for cvs to return a list of changes for the day or week? thanks --- James Chow ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Change history?
Chow, James writes: Is there anyway for cvs to return a list of changes for the day or week? Yes, look at the diff and log commands and their date options for specifying revisions. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Change history?
On Thu, 9 Jan 2003, Chow, James wrote: hi Is there anyway for cvs to return a list of changes for the day or week? Yes; learn how to use the ``cvs log'' command's -D (date) parameter. There are some utilities that munge the output of CVS log to generate a more useful report, such as a ChangeLog report. Take a look at, for instance: http://www.freshmeat.net/projects/cvs2cl.pl ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Change history?
Configure bonsai on your system by using this you can query CVS for any checkin any user's checkin and any checkins betwenn 2 dates regards, Amit -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] Sent: Friday, January 10, 2003 3:01 AM To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Subject: Re: Change history? Chow, James writes: Is there anyway for cvs to return a list of changes for the day or week? Yes, look at the diff and log commands and their date options for specifying revisions. -Larry Jones I told her to expect you to deny everything. -- Calvin ___ 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: How is a patch applied to CVS?
On Thu, Jan 09, 2003 at 11:14:59AM +1100, Matthew Herrmann wrote: But can patch be run in such a way that it generates conflict markers instead of .rej files? I don't think so. Or is diff3 the go here instead? Yup. There's also merge. That's part of the RCS distribution; it's an intermediate layer between rcsmerge (which understands RCS files, revisions, etc., and which is thus pretty irrelevent in a CVS context) and diff3 (which does the real work). I don't recall offhand what value merge adds to diff3 -- a quick glance at its man page doesn't show me anything that diff3 isn't already doing -- but there must be something I missed, and whatever it is, it might be useful :-) Of course, diff3 is what CVS uses internally. It might be possible to structure your development process such that there's a CVS branch that the patch will apply cleanly to, so you can then use a CVS merge rather than messing with diff3 yourself. That's the theory anyway. I looked into this a few months ago, and found that I didn't have the time to script a solution that would work in our specific situation. In an open-source situation, with people submitting patches against various releases, nightly snapshots, and/or random cvs updates, I doubt this sort of approach has a chance. You'd end up with *zillions* of little one-revision branches, one for each submitted patch. Ick! -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Just Say No to the faceless cannonfodder stereotype. - http://www.ainurin.net/ (an Orc site) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
