Re: cvs ext (ssh), but no shell access..
In article [EMAIL PROTECTED], Wim Bertels [EMAIL PROTECTED] wrote: Houdi, Its a remote clients/server setup, cvs is up and running, but by using the ext method users automatically gain shell access to the cvs server, this in NOT intended, how do you solve this. (i need to use ssh because i have to use pam_ldap to authenticate the cvs-users) I don't worry about it. Make sure nothing but CVS is on the machine, and users won't have access to anything they don't already have access to. No additional risk. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: normalizing files and old revisions
Sorry if this is a duplicate. My sendmail update didn't go as smooth as I'd thought. :-/ In article [EMAIL PROTECTED], Andreas Klauer [EMAIL PROTECTED] wrote: The repository already contains files which use tabs, CRLF, et cetera. Corresponding diffs to old revisions already contain loads of unnecessary whitespace changes. I'd like to get rid of these diffs, to make comparisons between never revisions (which use filter) and older revisions (which didn't have the filter) possible without getting all this whitespace changes junk. [EMAIL PROTECTED]:25am]~(501) cvs diff --help -w --ignore-all-space Ignore all white space. -b --ignore-space-change Ignore changes in the amount of white space. -B --ignore-blank-lines Ignore changes whose lines are all blank. I suspect those options should provide you with enough control to avoid the necessity of those changes. As an SCM person, I look upon a change such as this with agast. It's equivalent to outdating a version of a file that has a bug in it. You simply don't do that! mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: normalizing files and old revisions
In article [EMAIL PROTECTED], Andreas Klauer [EMAIL PROTECTED] wrote: Now, to my main problem: The repository already contains files which use tabs, CRLF, et cetera. Corresponding diffs to old revisions already contain loads of unnecessary whitespace changes. I'd like to get rid of these diffs, to make comparisons between never revisions (which use filter) and older revisions (which didn't have the filter) possible without getting all this whitespace changes junk. cvs diff --help -w --ignore-all-space Ignore all white space. -b --ignore-space-change Ignore changes in the amount of white space. -B --ignore-blank-lines Ignore changes whose lines are all blank. -I RE --ignore-matching-lines=RE Ignore changes whose lines all match RE. Those options may use enough to accomplish your goals for the history. One thing I strongly feel about history is, it should never lie. That's how they were checked in. I may not like them, but I'll leave them be. It's like removing old versions that checked in bugs. Just something you don't do. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Files beginning with a minus sign
In article [EMAIL PROTECTED], Franky Van Liedekerke [EMAIL PROTECTED] wrote: wanted to delete the file. Marking the file for deletion was ok, but the commit is not working. The cvs commit command at first complained about this file with unknown option, so I called cvs like this: http://www.cvshome.org/cyclic/cvs/dev-diff-hyphen.txt Someday I should really write that sanity check and resubmit the patch. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit inconsistency: Up-to-date check did not fail though itshould have !
In article [EMAIL PROTECTED], Reinstein, Shlomo [EMAIL PROTECTED] wrote: - User B commits his changes to p, without first updating his working copy. Against all expectations, user B succeeds to commit even though his working copy is not up to date, leading to an unstable latest version of the project in the repository. Hmm... originally I was wondering, How would this create an unstable latest version? The only scenario I can think of is where user B starts making use of a function that user A has changed/removed, and that function had never been used in that file before. In any other case, the file that user B was changing would have to have been modified by user A. Correct? As a side note, this state is easily achieved by using Perforce as well. And, I would imagine, any number of other systems. To be honest, this is the first time I've ever heard of CVS working in this way. But then, 99% of my cvs usage is using client/server or single user using a single check out. Actually, I can't even find it in the documentation. Could someone point out to me where it says that CVS will complain about an Up-to-date check for files not being checked in? From my point of view, complaining about unchanged files is a bug, not an undocumented feature. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: FW: Commit inconsistency: Up-to-date check did not fail thoughit should have !
In article [EMAIL PROTECTED], Eric Siegerman [EMAIL PROTECTED] wrote: On Mon, Feb 24, 2003 at 03:36:58PM +0200, Reinstein, Shlomo wrote: I just wonder how come this does not cause problems in the development of large projects that are kept in CVS. So do I! Probably because, in most cases, it simply doesn't matter, and the speed improvement you get it worth the minor inconvenience. As I posted before, at least one other CM system, namely Perforce, acts in a similar manner. And there are several large systems under P4 control, including Open Source ones (Perl, for instance). I imagine that the protocol will work either way, so if it bothers enough people, make it a run time configuration option. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Storing static code
In article [EMAIL PROTECTED], Steve Harris [EMAIL PROTECTED] wrote: WE have an existing cvs setup where we would like to hold the original code that the vendor has sent out - before we mod'd it - so we can do diffs against the original code (assume we originally imported code that had already been mod'd) to find out what has changed. This scenario is precisely why CVS was invented. In the manual, look up stuff on vendor branches for recommended procedures. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Linex need serious concurent version control software ?
In article [EMAIL PROTECTED], Bogdan [EMAIL PROTECTED] wrote: I just wander if cvs can make merging kylix project files? My guess is that it will make a mess. I have used CVS (and perforce) to manage the .bpr files on other platforms. It's doable, if a bit of a pain. It's pretty much a straight forward XML file. However, it IS formated by software which likes to throw in line breaks at obnoxious points. For example, instead of something like the xml equivalent of: SOURCES = foo.c bar.c baz.c it does SOURCES = foo.c bar.c baz.c with line wraps (probably around 80 chars or so). I believe it also keeps a listing for object files as well. So, if you add a new file at the beginning, it changes a LOT of lines. So, yes, that can make merging a significant pain. But I don't know of any tool that would handle that well. What I usually do is merge, handle the sources conflicts, and nuke the object file listing, and let the borland tools rebuild those parts of it. Occasionally there may be some conflicts with defines and what not. But, to be honest, most of those issues exist with Makefile as well. At least with being xml, you could probably write a filter that could put each item on it's own line, which could reduce conflicts. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS queue tool?
In article [EMAIL PROTECTED], Derrek Leute [EMAIL PROTECTED] wrote: I *could* run a mirrored repository on my laptop and then merge that with the primary repository when I return. But I don't know how to do that Isn't this what cvsup is for? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: switch branch to main trunk ?
In article 007001c1de9d$77ad1c70$590aa8c0@GEORGEX, Rabbit Xu [EMAIL PROTECTED] wrote: -=-=-=-=-=- hello all: I use cvs and work in branch of cvs.now I want to change this branch to main trunk and change original main trunk to a branch. How to do? The way you worded it makes me wonder *why* you want to do this. Are you sure you need to? Meanwhile, taking your request literally, I see two ways of interpretting it. One, you want to rotate branches. Two, that you want to merge the branch onto main then branch again. In the first case, create a new branch off of main, then merge the old branch onto main. Something like this: cvs up -A # make sure on main branch cvs tag newbranch_bp # make a branch point tag for reference cvs tag -b -r newbranch_bp newbranch # create new branch cvs up -j oldbranch # merge changes from old branch onto main # do fixups here cvs commit -m merged oldbranch onto main In the second case, do something like: cvs up -A cvs up -j oldbranch # do fixups here cvs commit -m merged oldbranch onto main cvs tag newbranch_bp cvs tag -b -r newbranch_bp newbranch mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to baseline project for subsequent releases
In article [EMAIL PROTECTED], msenin [EMAIL PROTECTED] wrote: How do we do that with CVS? Use tags. I believe task can be simplified if we tagged all files with same version name for every release, but we'd preffer not to change versions of files that haven't been modified. A version can have multiple tags, so no need to cause a bump in version number if nothing changed. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: english text only?
In article [EMAIL PROTECTED], Greg A. Woods [EMAIL PROTECTED] wrote: Those of you looking for a different context to host this forum in seem to forget that CVS _is_ GNU software, and having the mailing list hosted @gnu.org is quite important. For many of us the highly over- If it *is* gnu software, why is it hosted in the non-gnu area on ftp.gnu.org? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: revision number less than 1.1
In article a28pfa$1dj6$[EMAIL PROTECTED], Petr Aubrecht [EMAIL PROTECTED] wrote: The idea was to put $Revision$ into configuration file as a version number of the software. Then I have automatically increasing version number (like This is a good idea if you want the user to be able to identify the revision of each component (such as using ident or what commands). But not for identifying the version of the release. in Borland C++ Builder). It allows frequent releases and stay sure the user has the latest version. I don't like to do it manually (every day). Borland C++ Builder is a build system. Not an SCM system. While it may be wise to keep track of the information in CVS, it should be the build system (be it make or whatever) that assigns identification to the release. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Forking off a remote public cvs. Howto merge the parallelldevelopment?
In article 1010671210.23474.7.camel@erik, Erik Sjölund [EMAIL PROTECTED] wrote: What possibilities are there to merge in new releases from the public cvs into our forked code in the future? This type of scenario was EXACTLY why CVS was invented in the first place. It doesn't matter much that they other project is in CVS, so ignore that point for now. Just treat it as vendor sources and read up on the CVS docs on vendor branches. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: conflict algorithm
On Mon, Jan 07, 2002 at 04:39:17PM -0500, Greg A. Woods wrote: My version shows all the conflicting lines from all the three files, not just the latter two, and I find this almost infinitely easier to deal with when manually resolving the conflicts. somefile changed line[s] unique to local copy of somefile changed line[s] unique to local copy of somefile changed line[s] unique to local copy of somefile ||| 1.X matching line[s] unique to version 1.X of somefile matching line[s] unique to version 1.X of somefile matching line[s] unique to version 1.X of somefile === matching line[s] unique to version 1.Y of somefile matching line[s] unique to version 1.Y of somefile matching line[s] unique to version 1.Y of somefile 1.Y This is very similar to what Perforce does. I haven't yet decided if I like it or not. But I think it would be neat to have a cvs up -gw option. ;- mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Timestamp handling in checkout vs update
On Mon, Jan 07, 2002 at 04:13:46PM -0800, Harper, Don wrote: seems to me that operations such as 'update -C' should set the timestamp back to the commit time just like checkout. Consider make. You modify the local file, make. You now have at least an object file, if not an entire executable built with that modified file. You do up -C. Now, if it resets the date back to the original date, a subsequent make is going to see that the source file is older than the object file, and is not going to rebuild the system. Not a good scenario. Better to have up (-C or no) use the current time so that make will do a rebuild. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cannot commit ... sticky tags
On Mon, Jan 07, 2002 at 05:12:44PM -0800, Schwenk, Jeanie wrote: Today, as I go to check in several files, I did a cvs update. No problem. cvs update -A mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Unset $HOME before restarting inetd!
On Fri, Dec 21, 2001 at 02:57:23PM -0800, agreatham wrote: root@localhost:~ unset HOME root@localhost:/root /etc/rc.d/inetd start Better, put the unset HOME inside the /etc/rc.d/inetd script. Though I suspect that a simple ``skill -HUP inetd'' would have worked in this particular case. (skill is a linux-ism that is pretty close to something like kill `pidof ...`. Actually, depending on which package your /bin/kill came from, /bin/kill -HUP inetd might have worked as well, but I've some to use skill by default) mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs -- ssh
On Thu, Nov 01, 2001 at 10:22:08PM +0100, SaPeR wrote: how to connect to a remote cvs server using ssh (i tried with sth like this but it didn't work: cvs -d:ext:[EMAIL PROTECTED]:/directory/on/the/server checkout modul export CVS_RSH=ssh ) ? Just to verify: You did to the export CVS_RSH=ssh _before_ the cvs command, correct? Outside of that, what if you try a space between -d and :ext:? Also, consider adding -t to cvs to trace what it's doing. It might point out an obvious configuration error. cvs -t -d :ext:[EMAIL PROTECTED]:/directory/on/the/server checkout module mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Why can't root check in files?
On Thu, Oct 11, 2001 at 03:37:47PM +1000, [EMAIL PROTECTED] wrote: However, I still think that I'm onto something good here - the cvs control of Unix config files. Unfortunately, this sensible cvs feature utterly prevents me from providing this useful facility. Use something like GNU's cfengine (http://www.gnu.org/software/cfengine/cfengine.html) and put those configuration files under CVS control. Check the CVS archives. Been discussed here several times in the past. :- mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checkout text files with the Unix LF (Oxa) - from command line
On Fri, Oct 05, 2001 at 09:40:14AM +0200, PS wrote: I use WinCvs with checked option Checkout text files with the Unix LF (Oxa). I would consider this a design flaw in WinCvs. And then I have a problem, because all updated files have every second line empty. What to do to run that option (Unix LF) when I use cvs from command line in Windows. You don't. Either check the files out on a Unix box, or make it part of your build process to transform the files from native format to Unix format. check out file1.native switch platform: case DOS|NT: dos2unix file1.native file1.unix case UNIX: cp file1.native file1.unix case MAC: mac2unix file1.native file1.unix default: error out unsupported platform use file1.unix mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: set -kb on import ?
On Thu, Oct 04, 2001 at 06:02:42PM -0400, Matt McClure wrote: You can add a line like *.jpg -k 'b' to the cvswrappers file in your CVSROOT module. I'd actually suggest something like: *.[jJ][pP][gG] -k 'b' mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: os390
On Fri, Sep 21, 2001 at 11:35:23PM +, r w wrote: hope this isnt a lame question.. anyone gotten cvs to work on an os390 (no http://mail.gnu.org/pipermail/info-cvs/2001-February/012766.html It still probably needs more testers before the necessary changes could be considered for rolling back into the main tree. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: lock in problem
On Tue, Sep 18, 2001 at 10:56:53AM -0700, hemkumar balla wrote: cvs admin: [13:25:53] waiting for hemkumar's lock in /home/cvsroot/sample Go to a search engine, like, say google.com and try the following: info-cvs waiting for lock in One promising result was: http://mail.gnu.org/pipermail/info-cvs/2000-October/013058.html After that, you may want to try adding site:mail.gnu.org to the search to focus on those archives. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 0D0A = 0A = 0D0A
On Tue, Sep 18, 2001 at 01:15:01PM -0700, Jimmy Rimmer wrote: That's the real problem. Windows' RSH does CR/LF translation, and the Cygwin RSH doesn't. The key is to make sure both users use the same version of rsh.exe by either defining the CVS_RSH variable (I don't know if this works), or by renaming/moving the inappropriate RSH.EXE. What about the built in :server: method? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Can cvs support distributed development usage.
On Tue, Sep 18, 2001 at 04:09:43AM +, Kaz Kylheku wrote: updating. So having one additional level of caching in the form of a local repository won't really help, other than perhaps make your initial checkout much faster. One thing that I often do is keep a local copy of a working area checked out somewhere, and when I want to start a new sandbox, instead of do a checkout, I copy the working copy over to the new area, then do a cvs up. Occasionally I will update the initial working area. I believe that a few CVS hosted projects use that method for initial distribution (I want to say Mozilla, and possibly wine). You download a tar file and unpack it, and then you can do cvs commands directly from there. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Security
On Sun, Sep 16, 2001 at 08:37:26PM -0400, Stevie O wrote: The method I suggestion is no stronger than pserver is; it simply makes it harder for someone to sniff the password off the network (which is Harder how? I don't have to decrypt your DES encrypted password. I just have to use my hacked cvs client to take your DES encrypted password from the command line and use it directly. It gains nothing. This is what MS added to SMB. And it didn't gain them anything either. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checking in links to source control
On Fri, Sep 14, 2001 at 02:13:20PM -0700, Edward Peschko wrote: 2) permissions - cross-platform for all of unix, cross-platform for all of NT, cross-platform for all of Mac. Permissions on what unix filesystem? One person is using AFS with ACLs and another is using standard ugo. -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to handle more than one project??
On Fri, Sep 14, 2001 at 12:31:44AM +0530, P.V.Sridhar Reddy wrote: My problems are: 1) How do i create the repositories??? cvs import a file to start with (say, a readme explaining what the project is). Or do something like cvs co -l . ; mkdir foo ; cvs add foo 2) I dont want the developers of one project to be able to do any kind of CVS operations on other project. 3) Within in a project, i want only one person to be able to checkin, and for others only checkout permissions. Both of these can be handled with usual unix permissions. Use g+rs on the top level directory, for instance. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS management of /etc - permissions problem
On Thu, Sep 13, 2001 at 03:15:39PM +1000, [EMAIL PROTECTED] wrote: To this end I've written a script which checks in as much or as little of /etc's text files as you want. And now I've found that CVS is You might consider looking at cfengine, or something similar. You could then use cvs to manage the input to cfengine, and cfengine would be your build system to manage the configuration files. From: Jim Kingdon [EMAIL PROTECTED] Subject: Re: CVS and PreservePermissions Date: Thu, 21 Dec 2000 12:46:55 -0500 (EST) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] that the code is actually used. And the code is also in #ifdef PRESERVE_PERMISSIONS_SUPPORT (still in 1.11 and development sources, just not enabled). This sounds like it would be perfect, when implemented. Actually, I thought the intent was to remove all remnants of this experiment. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to handle more than one project??
On Thu, Sep 13, 2001 at 12:10:11PM +0100, Philip Lijnzaad wrote: On Fri, Sep 14, 2001 at 12:31:44AM +0530, P.V.Sridhar Reddy wrote: 1) How do i create the repositories??? cvs import a file to start with (say, a readme explaining what the project is). Or do something like cvs co -l . ; mkdir foo ; cvs add foo Often it is useful to first create an empty repository as Oh damn! I misread that as create modules. Must get more sleep. Both of these can be handled with usual unix permissions. Use g+rs on the top level directory, for instance. why g+s ? g+rx would seem more logical (g+s sets directory-groupid on file creation, but files won't be created). But don't you still want g+s on the directories so that new directories automatically inherit those group permissions? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and RSH--please clarify
On Wed, Sep 12, 2001 at 04:25:28PM -0700, Paddy T wrote: In most machines here,CVS works fine even though rsh is not installed at all in that machine. We have our CVSROOT set as :server: for all Apparently :server: users an internal rsh implementation. developers(except those working on linux who have :ext:) which according to the manual uses rsh to Which appears to not be available on the unix version (more likely, not available by default). perform cvs operations.So how is cvs working from these machines? one on of the linux boxes, do something like cvs -t up. The -t turns on some tracing, and you can watch it execute the rsh command. Most likely cvs uses standard pipe() followed by a fork()/exec() to spawn rsh in such a way that stdin/stdout of the rsh command is tied to the pipe. The rsh command executes the cvs command with the option server on the remote machine. That remote cvs process then uses the cvs protocol across it's stdin/stdout (which is tied to the local machine's pipe) and does all of it's network stuff. For the nt part, the stuff that rsh does is built into the binary, and so it's your usual open a socket and connect to a port type of stuff. Only in this case, the port is the rcmd(?) port, which fires up the rshd, and cvs then tells the shell rshd gives it to start cvs server. mrc Also is it mandatory that we should we use :ext for linux clients? Probably. It might be possible to build the linux version with :server: support, but why bother :ext: works? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Remote cvs and security
On Mon, Sep 10, 2001 at 08:41:34AM -0500, Colin Bester wrote: Creating CVSROOT/passwd file is fine for attempting to protect users system passwords, but still leaves the repository vunerable itself. This is a red herring. Avoid using pserver, Give users accounts, and set them up using ssh. If you are that paranoid about your developers compromising system passwords, then put them on a separate system that has no privileges, so even if they do get root, they can't affect the rest of your network. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How well does CVS handle other types of data?
On Sat, Jul 14, 2001 at 02:07:58PM -0400, Greg A. Woods wrote: The existing warning of a conflict during the merge is sufficient to alert the user to a possible problem. No, it is not. The initial warning is only just that -- an initial warning. CVS must now continue to detect that the conflict remains until it has been explicitly resolved and in the mean time avoid doing anything further that will damage the file. Except that CVS doesn't continue to detect conflicts. A simple touch(1) of the file is sufficient to mark the file as fixed. And that will work on any file type. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How well does CVS handle other types of data?
On Fri, Jul 13, 2001 at 04:03:09PM -0400, Greg A. Woods wrote: [ On Friday, July 13, 2001 at 11:47:27 (-0700), Mike Castle wrote: ] presenting two versions of the files in question to the user. Currently CVS does not present to versions of the file to the user. Yes it does. I tested it before I posted that. nexus@thune[8:40pm]~/a/test(533) cvs up -j foo cvs update: nonmergeable file needs merge cvs update: revision 1.1.2.1 from repository is now in file cvs update: file from working directory is now in .#file.1.2 C file nexus@thune[8:40pm]~/a/test(534) ls -latr total 20 drwx--5 nexususers4096 Jul 13 20:38 ../ -rw---1 nexususers 22 Jul 13 20:40 .#file.1.2 -rw-r--r--1 nexususers 14 Jul 13 20:40 file drwx--2 nexususers4096 Jul 13 20:40 CVS/ drwx--3 nexususers4096 Jul 13 20:40 ./ mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How can i give access rights at Directory level in CVS.
On Thu, Jul 12, 2001 at 10:21:52AM +0530, Bhavaniprasad Polimetla wrote: How can i implement this? Standard unix groups. Make chgrp foo login_module. Add john to foo. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Correct options for export
On Thu, Jul 12, 2001 at 09:24:58PM +0200, Ingolf Steinbach wrote: Is there consensus among the developers with write access to the CVS source that the cases in which a file which was added with -kb needs to be checked out / updated / exported with keyword handling any other than -kb are so rare that a patch implementing the suggested change would be accepted? For -kb, yes, I think it would be rejected. Because it would break backwards compatibility. However, there has been talk in the past that if ANOTHER -k option (or some other mechanism) was created that acted like -kb, but couldn't be overridden, then that would be worth while. Check the archives for around October, 2000. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How well does CVS handle other types of data?
On Wed, Jul 11, 2001 at 02:29:08PM -0400, Jeff King wrote: Exactly. Source code and binary data are quite conceptually different. Not always. Both can be used to create an executable (embedded icons, for instance). So, from the viewpoint of source items that are used to make a final executable, they ARE conceptually the same. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Correct options for export
On Wed, Jul 11, 2001 at 08:00:23PM +0200, Ingolf Steinbach wrote: if they were checked in as binary? I believe that many users would appreciate a change which ignores -k for binary files. So when are you going to contribute the code that does it? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: moving files from a branch to the Main trunk
On Wed, Jul 11, 2001 at 11:33:48AM -0700, Ketan Shah wrote: HI I have many files that are branched and have the tag next_release. I would like to collapse this branch and have these files on the main trunk. so that when a developer checks out files he/she does not have to use the -r option. cvs up -A cvs up -j next_release [resolve any conflicts] cvs commit -m merged in changes done on next_release branch -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: moving files from a branch to the Main trunk-clarification
On Wed, Jul 11, 2001 at 01:00:46PM -0700, Ketan Shah wrote:
Clarification from my earlier post.
I do NOT want to merge my changes.
I just want the branched file on the main trunk.
In a separate area:
cvs export -r branch
In the sandbox:
cvs up -A
find . -name CVS -prune -o -type f -print | xargs rm
copy over exported stuff.
cvs -n up | awk '/^U/ {print $2}' | xargs -r cvs rm
cvs -n up | awk '/^\?/ {print $2}' | xargs -r cvs add
verify everything is as it should be example.. the above would miss
new directories
cvs commit -m replaced main branch with branch foo
--
Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/
We are all of us living in the shadow of Manhattan. -- Watchmen
fatal (You are in a maze of twisty compiler features, all different); -- gcc
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How well does CVS handle other types of data?
On Wed, Jul 11, 2001 at 04:31:42PM -0400, Jeff King wrote: There could be hooks for handling mergable binary formats, but at that point I think a tool other than CVS would be more appropriate. Can you suggest such a tool? That's free? That supports networking? That supports branching? Exactly what IS the better mousetrap? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How well does CVS handle other types of data?
On Tue, Jul 10, 2001 at 08:56:09AM -0400, Larry Jones wrote: Since such file don't allow for concurrent modifications, I can't imagine why you'd want to use the *Concurrent* Versions System to store them. It's free and has decent networking capabilities? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS listing
On Sat, Jul 07, 2001 at 01:01:41PM +0200, V. van Adrighem wrote: What I am trying to find out is, with wich command can I list all apps on cvs.gnome.org? I can see all of the apps via webcvs, so I thought: This should be possible via cvs itself. But until now I have had no luck. Could you help me with this? cvs co -c -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .doc file concerns
On Tue, Jun 26, 2001 at 04:13:38PM -0700, Paul Sander wrote: The thing is, most writers seem to prefer WYSIWYG editors such as Word or Frame Maker to using mark-up languages. This is reasonable, because they're much more productive with such tools, especially since they're much more concerned with an attractive presentation than are engineers who happen to write simple documents. Precisely the point. Attractive presentation means squat if the content is useless. Concentrate on the content, not the presentation. Of course, I wouldn't consider a 200+ page user/installation guide a simple document. But then, that's just me. Choosing an inferior tool just because the version control system can't handle a full-featured one is a poor way to work. *shrug* Name calling. I consider Word to be an inferior tool. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: .doc file concerns
On Mon, Jun 25, 2001 at 02:56:34PM -0700, Anita Chacko wrote: Any alternate way to handle .doc files? Switch from using binary only formats. All of the items you mentioned are problems. Proprietary formats like Word documents, just can't be handled well. There is nothing you can do except not use them. Personally, I'd recommend using LaTeX to do your documentation. We used that with cvs (under win32!) and it worked great. We able to make meaningful merges of documentation. People could easily, see what was changed (using diff). It's cross platform (I actually did my work under Linux). And personally, I found it MUCH easier to use than Word (I always get lost in word. With TeX, I was able to focus on the content of what I wanted to write, and worry about how to mark up the structure later). RTF _might_ be an option, if it uses reasonable formatting in the rtf doc (ie, not all one big long line). For the rest of the CVS group: What about other word processors in the win32/dos world? Do any word processors use text only format these days? (Maybe for a history lesson, what word processors in the past may have used suitable file formats? NotaBene? Word Perfect? PC/Write or whatever it was called. I can't believe they've always been so dense...) mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS for student shared projects
On Tue, Jun 26, 2001 at 10:16:40AM +1000, Eddie Irvine wrote: Is CVS a good tool for group projects? I work at a university, It's great for the set up you describe. I'm leaning towards CVS. Will probably set up a CVS server on a seperate FreeBSD/OpenBSD or Linux box somewhere. Good choices. I guess the only thing that causes me some concern is the password field - I'd rather get them from NIS or LDAP. The easiest thing to do is completely forget about pserver. Use server mode of rsh or ssh. Give each user an account on the machine in question (using either NIS from a central server, or set up accounts locally). You might want to play with unix group permissions as well, just so the users don't accidently do something silly like nuke another groups archive. (If they do their own, good for them. Practical experience. If they do someone else's though...). Also, if any air of competition between the groups, might want to make it so they can't even read each other's repositories (more for sake of competition than anything else). LockDir setting might be of interest here. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS file locking question
On Thu, Jun 21, 2001 at 11:25:19PM +0200, Jens Vonderheide wrote: sandbox on the notebook and share it (as a Windows share) to the pc. I will never work on both computers at the same time, so there should not be any So you say now. But at some point, you will probably want to do that. issues with concurrent accesses. Or should I rather create two sandboxes and use commit/update to synchronize them? commit/update. If you have to go onto a branch to do that, fine. But commit/update always. Commit early, commit often. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Future CVS Development
On Tue, Jun 19, 2001 at 02:02:04PM -0400, Greg A. Woods wrote: I don't mind keeping the odd GIF or whatnot in my CVS repo because they never change and having everything in one place is convenient. However if I was a web site developer I'd probably want a separate tool for handling such things and using a separate tool wouldn't be cumbersome in that environment because it would often be separate people actually making the changes to, and creating, images and it would be very easy to have a build system that did the integration of images and text/html for publishing. One idea I had was using a database to keep track of binary objects, and using cvs to store the information about which item to pull out of the database (possibly with something like a size and checksum indicator as verification). Make it part of the build system, like creating output directories and setting up symlinks. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Off list comment (was: Re: Maintaining branches...)
Sorry to bring this up here, however, someone recently sent me an off list question regarding this particular message I had posted. Unfortunately, I fat fingered it and deleted the message. :- If the person is still interested, feel free to contact me again. Apologies, mrc On Thu, Jun 14, 2001 at 02:44:52PM -0700, Mike Castle wrote: On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote: Mike Castle wrote: But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. I'm going to pretend these are valid branch version numbers for the sake of argument. Thanks. Been a while since I've actually branched with CVS (stuck using perforce at work now). And since I never really pay attention to them, I always forget the numbering sequence it uses. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch I thought the idea here was that you could say merge branch 1.1.0 and CVS would say, you already merged change A on DATE - (s)kip this portion or (r)emerge? Sorry. I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5, apply patch was a matter of implementation, not presentation. If the user chose skip, then I'd imagine it'd work like that. I assume the remerge stuff would come from when cvs determining what it needs to apply, rather than actually at application time. Patch, for instance, determines it at application time. What about merging back and forth. User makes change 1.1-1.2, and merges it onto branch, then it gets merged back. Users would normally expect cvs to track that information and act accordingly (ie, not present any conflicts based upon that particular bit). But, since you could have +X amount of changes between the up -j and the commit, you really can't do that. There will be conflicts. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs: How to get last but one copy, from repository
On Fri, Jun 15, 2001 at 10:56:03AM +0530, Koti wrote: commit. So I want to delete the modifications done by last commit. How can i do it ? I have no exact idea, I think i can do by cvs update -p Correct. Specifically: cvs up -p -r 1.x file.c file.c Can i get last nut one copy in a single cvs update. or i need to update once for one file. Once per file. If it was more than 3 files, it might be worth it to script it. But for just three, it's easy to just do a cvs stat, see the current number, and back off one revision. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: (no subject)
On Thu, Jun 14, 2001 at 01:58:11PM -0500, Alex Flores wrote: D:\CVS\CVSwork\practice_foldercvs update -j rel_1_0_practice practice_alex.cpp M practice_alex.cpp RCS file: d:/cvs/practice_folder/practice_alex.cpp,v retrieving revision 1.5 retrieving revision 1.5.2.2 Merging differences between 1.5 and 1.5.2.2 into practice_alex.cpp rcsmerge: warning: conflicts during merge That this point, you need to edit the file and resolve the conflicts. Look for lines with , ===, and in them. They mark the boundaries of the conflicting areas. D:\CVS\CVSwork\practice_foldercvs update -j 1.5.2.2 -j 1.9 practice_alex.cpp C practice_alex.cpp I'm not sure this command makes send here. 1.9 is on the main branch, which you said you were working on already. So what this command will do is create a diff between 1.5.2.2 and 1.9 and apply it. Since that would essentially be applying the same set of changes back onto yourself, it doesn't seem to make much sense. D:\CVS\CVSwork\practice_foldercvs commit cvs commit: Examining . cvs [commit aborted]: end of file from server (consult above messages if any) You can't do a commit until you resolve the conflicts above. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 03:26:31PM -0400, Derek R. Price wrote: Mike Castle wrote: And I think that this complete merging happens less than you might think. It cannot handle the situation where a specific set of changes is migrated before another (i.e., -j tag1 -j tag2). It may not even be off of an immediate branch, but rather a couple over. What can't it handle about this and why? Originally I was thinking only highwater marks. But I guess something like a .newsrc style range/set would work. (Ok, what IS that data structure properly called?) But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. 1.1.0.3 is made, and that particular change is needed immediately on the branch branch, so only it is moved over. So 1.2 == 1.1 + 1.1.0.3. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 05:03:58PM -0400, Derek R. Price wrote: Mike Castle wrote: But consider the following sequence: branch at 1.1. Branch has 1.1.0.1 and 1.1.0.2. I'm going to pretend these are valid branch version numbers for the sake of argument. Thanks. Been a while since I've actually branched with CVS (stuck using perforce at work now). And since I never really pay attention to them, I always forget the numbering sequence it uses. Changes 1.1.0.4 and 1.1.0.5 are made. Now we want to migrate all of those changes onto the main branch. So now we have to be able to tell cvs to: diff -r1.1 -r1.1.0.2, apply patch diff -r1.1.0.3 -r1.1.0.5, apply patch I thought the idea here was that you could say merge branch 1.1.0 and CVS would say, you already merged change A on DATE - (s)kip this portion or (r)emerge? Sorry. I mean the -r1.1 -r1.1.0.2, apply patch, -r1.1.0.3, -r1.1.0.5, apply patch was a matter of implementation, not presentation. If the user chose skip, then I'd imagine it'd work like that. I assume the remerge stuff would come from when cvs determining what it needs to apply, rather than actually at application time. Patch, for instance, determines it at application time. What about merging back and forth. User makes change 1.1-1.2, and merges it onto branch, then it gets merged back. Users would normally expect cvs to track that information and act accordingly (ie, not present any conflicts based upon that particular bit). But, since you could have +X amount of changes between the up -j and the commit, you really can't do that. There will be conflicts. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Thu, Jun 14, 2001 at 10:15:16PM -0700, Paul Sander wrote: Your first case is really two merges, one requiring the user to supply version 1.1.0.3 as the common contributor. The other is a single join with version 1.1.0.2. You could also do this: version 1.5 = 1.4 + ( 1.1.0.5 - 1.1 ) And then resolve the inevitable conflicts resulting from the first bug-fix merge. This is how CVS currently works. Two points: If I do that manually, I can easily avoid having to deal with a conflict by doing it in multiple stages. When I want to merge all the things in, I merge in the diff from 1.1 - 1.1.0.2. Then I apply the diff from 1.1.0.3 - current. Because I know I've already applied 1.1.0.3. If you're going to automate this, this is how I would expect the automation to work. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Wed, Jun 13, 2001 at 10:25:18PM -0400, Ralph Mack wrote: Maybe the term merge is ambiguous. My concept of a merge is: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. make a diff from the reference version to the to version 3. merge the diffs (preferably with optional user input), and 4. apply the result to the to version. Does CVS use a different merge concept entirely? Not quite, but close: 0. select a reference version and a from and to version 1. make a diff from the reference version to the from version 2. apply the diff, as a patch, to the to version They don't even have to have a common ancestor. It can be any two versions, and really, in any order (example, maybe you want to back out a specific set of changes on a particular branch). mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Maintaining branches...
On Wed, Jun 13, 2001 at 09:00:09PM -0700, Paul Sander wrote: If CVS had and equivalent to ClearCase' merge arrows, then a more intelligent choice could be made for the reference version, reducing the distances of the diffs and eliminating the needless conflicts. Of course, that's nearly impossible to do within CVS. cvs up -j change change change change cvs up change change change cvs up cvs commit compare to cvs up -j change change chang echange oop... don't like that find . -name '*.[ch]' | xargs rm cvs up change change change cvs up cvs commit Which is merged? which isn't? There would probably have to be an extra lot of special casing to handle the fact that this file had had a -j done onto it, but not yet committed. And if it had been deleted and updated, mark that -j as undone. Plus, let's say you do the following: cvs up -r branch cvs tag tag1 cvs up -A cvs up -j branchpoint -j tag1 cvs commit cvs up -r branch cvs tag tag2 cvs up -A cvs up -j tag1 -j tag2 cvs commit Which is how one usually does multiple merges. But lets say you have some changes you don't want to merge. So you purposefully move one of the tags past the version so those changes don't get looked at. Not something you could easily do with cvs automatically tracking it. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Use of CVS on large scales
On Fri, Jun 08, 2001 at 11:40:35AM +1000, Lucas Chan wrote: Something like... a case study of a large software company using CVS would be pefect (I imagine). Hmmm... let's see... Perhap's he's heard of Netscape? (think mozilla.org). HP uses it (Example, look for the book Practical Software Configuration Management by Mikkelsen and Pherigo... both HP people, and it's part of HP's Professional Books series). Maybe not for everthing, but they use it. Sourceforge.net is a massive site. Check for yourself, of course, but I thought I heard something like 180,000 registered users across 20,000 projects. Perhaps that not scalable enough? Then again, while I think at least one (if not all three) of the *BSD projects use CVS, I think they have had complaints about scalability. I'm not sure what their bottlenecks where, but I'm sure that a web/degoogleja search would turn up useful info. Of course, something like clearcase, while it IS extremely powerful, it a hell of a resource hog. You need a top of the line server to host it if you want reasonable performance (while you could probably start off using cvs on an old 486 hanging around in a corner somewhere). It also has a lot higher administrative overhead. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: WinCVS with ssh password
On Tue, Jun 05, 2001 at 09:21:40PM -0400, Daniel Stolz wrote: tell, all of the instructions imply that you set up public key authentication so that a password is not required. I think I'd like to avoid that. You could create a public key that is protected by a passphrase. That is about as secure as using a password. Try that and see how it works. (someone recently posted the instructions they use internally for using ssh/cvs like this. You could check the archives for that. If those instructions say do not enter a passphrase, then you should enter one anyway). mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS - SSH question
On Fri, Jun 01, 2001 at 10:17:21AM -0400, Robert Briggs wrote: Greetings, My question is how to get WinCVS to work with SSH without having to enter the password in the SSH window with every command that is executed. This is more of an ssh question really, and might be better answered in an ssh specific forum (say, the newsgroup comp.security.ssh). But, one way is to use ssh-keygen to create a public/private key pair, and put the public key on the remote side (don't use a passphrase, of course). But this doesn't realy offer a lot of security. Anyone with physical access can then take your private key and use it wherever they like. I'm not sure how useful something like ssh-agent is in this case, I have no experience with it. But maybe that's what you need. mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: How to mirror a cvs repository?
On Fri, Jun 01, 2001 at 06:21:05PM +0200, Fabrice Gautier wrote: I would like to create a local cvs server which mirror another repository. I only have anonymous access to the original repository. would cvsup work in this scenario? mrc -- Mike Castle [EMAIL PROTECTED] www.netcom.com/~dalgoda/ We are all of us living in the shadow of Manhattan. -- Watchmen fatal (You are in a maze of twisty compiler features, all different); -- gcc ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: What did I do wrong?
On Fri, May 25, 2001 at 03:55:23PM -0700, Delos Nash wrote: cvs -d :exp:NAMEOFCOMPUTER:/CVSROOT checkout REPOSITORY It does the checkout just fine. Good. cvs -d :exp:NAMEOFCOMPUTER:/CVSROOT commit REPOSITORY You don't need the -d :exp:NAMEOFCOMPUTER:/CVSROOT on any other commands. This information is encoded in the files in the CVS directories. Also, the position in the command held by the string REPOSITORY is supposed the be the name of a specific file that you are committing. If you happen to have a file named RESPOSITORY, and you didn't change that file, then you will see what you described. cvs -d :exp:NAMEOFCOMPUTER:/CVSROOT add REPOSITORY/FILE_TO_ADD Again, no need for the -d option. Say's there is NO repository do a cvs checkout. Instead of RESPOSITORY/FILE_TO_ADD, do: cd directory cvs add file_to_add PS: Please shorten your .sig. 4 lines is standard, and many would say that's too many (obviously I don't fall into THAT category though ;-). -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Crazy idea - replace RCS backend with ClearCase...!!!
On Wed, May 23, 2001 at 12:04:15PM +0200, Weber, Mathias-Henry 1254 PPW-P1 wrote: The sync between the CC data base and the CVS repository is performed manually and of course cumbersome and errorprone. Would cvsup be a useful place to start here? Instead of two cvs repositories in sync, you want to keep a cvs repository and a clearcase vob in sync. Maybe cvsup would offer a better level of abstraction for this. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: move away file, it is in the way
On Tue, May 22, 2001 at 09:34:27PM +0200, Nils Holland wrote: Someone suggested that I re-checkout the sources as described above. Then, I should cd directly to /usr/src/kde-cvs/koffice and do a cvs upd there. This has worked - the above error message did not appear, and some files were properly updated. Still, I couldn't find any information about this move away... error message. If anyone on this mailing list can explain it to me and tell me why it initially occured and what I can do to prevent it from occuring again, I'd be very happy. Imagine the situation where there was a .y (yacc) file in the respository. You run yacc and get a .c file. Now someone adds the .c file to the archive (maybe not everyone has yacc). You do an update, and now the .c file that you created is in the way of the new one added to the repository. Ok, that's the situation that this is designed to cover. However, if you notice in your CVS/ directory, you'll have a file called Entries that has lines like the following: /ANNOUNCE/1.48/Wed May 2 00:43:50 2001//D2001.11.03.08.00.00 /AUTHORS/1.12/Wed May 24 15:54:06 2000//D2001.11.03.08.00.00 (wine in this case, if anyone cares). Now, if one of those lines was missing or corrupted some how, then cvs would think that you didn't download the file from cvs but generated it yourself, and it doesn't want to overwrite it. Somehow, most likely, your CVS/Entries file got corrupted. If this happens again, could you save off your CVS/* files and analyze them. Maybe something flaky happen (something stomped on them, ran out of disk space, hit control-\ at just the right time while cvs was running, cvs died on it's own). If necessary, maybe post them to the list. Meanwhile, if it's only a handful of files, you can manually delete the files that are in the way, and do cvs up again and that should be sufficient. If it's a lot of files, it will probably be easier to rm -rf the heirarchy and from the top level to a cvs up -Pd. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with LF -- CRLF trasnlation
On Wed, May 16, 2001 at 12:45:02AM -0400, Laine Stump wrote: Mike Castle [EMAIL PROTECTED] writes: Just don't do it. Or, if you insist on living dangerously (as I do) use editors and Well, yeah. I used certain implementations of vi to accomplish that as well. I just wasn't going to give anyone any ideas. ;- mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with LF -- CRLF trasnlation
On Wed, May 16, 2001 at 09:18:07AM -0500, Thornley, David wrote: Yesterday, I had a problem in that a coworker had a file in cygwin that had been edited with something that left it with Windows line endings, and CVS checked it into the main repository (on a Unix machine) with Windows line endings. Should I encourage developers to continue to use CVS on Cygwin, or should I push them to use WinCVS? Cygwin acted as if it were in the twilight zone between Windows and Unix in this case. I was afraid someone was going to ask this. :- I don't know Cygwin, but, until I got more comfortable with it, I'd either do EVERYTHING inside of cygwin, or nothing. I get the impression that as long as you don't mix and match what type of tools work on a file, you should be ok. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: handling of MsWord-Documents in CVS ?
On Wed, May 16, 2001 at 09:45:54PM +0200, Ferdinand Schaefer wrote: In my opinion Msword Documents need to be treated as binary files. Correct. Which means the archive grows. And you can't easily track what changes were made between documents. Dump word. Use TeX or roff. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with LF -- CRLF trasnlation
On Wed, May 16, 2001 at 04:30:20PM -0400, Echlin, Michael wrote: Suggesting to a windows user to use VI??? Heh. Actually I have a file open in VIM on my NT box right now. :- But what I'd usually do is use cvs to check out onto my NT box, smbfs mount it from my linux box, and use vi on linux (probably vim, but not certain) to edit the files. And compile on the NT box. But I was EXTREMLEY careful about making sure I didn't muck up any line endings. And I would not recommend it for anyone with less than 10 years experience in both Unix and DOS-like worlds. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS: Unknown Error 523
On Wed, May 16, 2001 at 05:41:52PM -0300, Christian Robottom Reis wrote: I've been using CVS for years now, without issue. However, my recent upgrade to linux-2.4.4 with reiserfs has caused me to get some peculiar errors. It only happens on checkouts from remote pservers (my local pserver works fine) onto NFS-mounted partitions. You're not using a reiserfs partition via NFS are you? There are known issues with that just plain not working. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Using Branches
On Tue, May 15, 2001 at 11:36:36AM -0500, Bob Stafford wrote: If my working copy is already tied to the branch, how do I make it revert to the main trunk without deleting the working copy and checking out the main trunk. cvs up -A -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: rsh access method question
On Tue, May 15, 2001 at 12:45:32PM -0700, Mark wrote: there another rsh for Windows that can be used? Should we use :server: or :ext:? I'd suggest :ext: with ssh. While you may not need to security associated with ssh, it does work well. Of course, if they don't want you installing sshd on the servers mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: problem with LF -- CRLF trasnlation
On Tue, May 15, 2001 at 11:15:25PM +0200, Jordi Castells wrote: I have the repository in a linux machine, but a have some windows projects, I try to checkout over the windows partition but I do not know how to change the method translation in some cases I couldn't quite parse that sentence. But. The rule of thumb is: only check out onto the machine that your are going to make changes on. If you are going to compile/edit on a Windows box, use a windows client. If you are going to compile/edit on a Unix box, use a Unix client. If you are going to compile/edit on a Mac, use a Mac client. Do NOT check out using Windows on to a Samba share, then edit on the Unix box. Do NOT check out using Linux onto a Windows share mounted with smbfs and then edit on the Windows box. It will cause you no end of grief if you try to mix and match platforms that have different line-ending policies. Just don't do it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Automatically increment build number
On Tue, May 08, 2001 at 04:04:34PM +0200, Weber, Mathias-Henry 1254 PPW-P1 wrote: Another problem with coupling the incrementing of the counter to the build process would mean that this would have to be performed on every client host. The clients run Windows NT which is not my favourite choice for running script jobs. Furthermore the clients are rather differently equipped in terms of software the only common tool for script programming would be a DOS batch job. Do you understand that I am still interested in a different solution? Just as a side note: The CMD Batch stuff on NT is *nearly* as powerful as Bourne shell. A lot more cumbersome, but nearly as powerful. Don't count is out so quickly. I did some scripting using Perforce's counter stuff, and NT's set /A to increment the build number. For something similar with cvs, you could probably keep a central area of build numbers and either use watches on them and cvs edit or cvs admin to enable an atomic update of the build number and so use cvs as your central database. Speaking of Perforce, what you want to do is basically a running counter of all changes committed to the respository. Perforce has such a thing built in actually, called a change number. If I was going to run a running counter like this, I'd probably use a 3rd party database like PostgresQL. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Date formats
On Tue, May 01, 2001 at 07:58:58PM -0400, Laurie Harper wrote: Can anyone tell me what CVS accepts as a valid date format with '-D'? I've tried all the formats from the man page, the format used in the results of 'cvs log' and a number of other variations, but all I get is 'cvs [server aborted]: Can't parse date/time: ...' I always use the ISO standard: -D 2001-05-01 -D 2001-05-01 13:00 Also relative: -D 4 hours ago -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Getting the list of files checkout
On Wed, Apr 25, 2001 at 12:26:15PM -0400, [EMAIL PROTECTED] wrote: is there a way to get the list of files that a user has currently check out for writing (edit command) cvs editors? -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Command ident
On Wed, Apr 25, 2001 at 05:34:05PM +0100, Rainer Stempel wrote: that command (from binaries as well). But it isn't in the download file of CVS and I haven't found it on the web-page (http://www.cvshome.org). It should be a part of the GNU RCS package. ftp://ftp.gnu.org/gnu/rcs mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Merge Management
On Wed, Apr 25, 2001 at 10:28:43AM -0700, Zachary M. Smith wrote: What I think i'd like to do is try to do the merges myself and delegate conflict resolution responsibilities to developers but CVS does not appear to have a very clean way of doing this. Has anybody had any luck with doing things this way? Any tips or tricks to make it a bit smoother? Usually what I do is the following: Try the merge myself. Do a build and some simple tests. If all of those pass, then I do the commit. If anything fails, I document what I did (the exact cvs commands necessary to generate the appropriate files, for instance) and pass that back to the developer via email. This way I don't for a commit of invalid code into the system, but the developer can still see things in the same way that I did. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Branch merging
On Tue, Apr 24, 2001 at 09:52:56AM -0700, Prakash Ranade wrote: branch 2.2 and commits to branch 2.2 for long period of time, How can we stop his commiting to branch 2.2. Also how can we took his changes and merge back into main tree. For his commits, I don't think there is much you can do except to inform him. Then have him update to the main branch with cvs up -A For migrating his changes over, you have a couple of options. If you tagged the 2.2 branch when you did the merge, you can do something like the following: cvs up -A # get on the main branch cvs up -j tag_from_last_merge -j branch_name_for_2_2 # resolve any conflicts or other issues here cvs commit -m merged in Joe's additional changes on the 2.2 branch If you didn't tag, then you will have to use the date you did the merge: cvs up -A cvs up -D 2001-04-05 -j branch_name_for_2_2 # resovle any conflicts or other issues here cvs commit -m merged in Joe's additional changes on the 2.2 branch Of course, in this scenario, you run into the chance of trying to remerge code already merged, but hopefully that won't be too bad. Whenever I migrate changes from one branch to another, I *always* use explicit tags. Makes it easier to handle situations like this. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Thu, Apr 12, 2001 at 08:34:33AM -1000, Joseph Dane wrote:
"Mike" == Mike Castle [EMAIL PROTECTED] writes:
Mike As I said in an earlier post, this can be scripted around.
can you give me an idea as to what such a script might look like?
wouldn't there have to be some sort of 'database' which kept track of
when/where the prior merges happened?
The database would be cvs tags.
Rather than actual code, this is what I used to do manually. (Mostly
because I was doing all of the work under NT and wasn't using Cygwin and
wasn't up to speed on the batch language improvements, so I never scripted
it before).
Lets say we have one branch, ver_2_0, and the main line.
I made a series of bug fixes to ver_2_0 and now I want to merge those onto
the main line.
(Be forwarned, I've actually not used cvs in a while, now working in a
perforce shop, so if I screw up syntax somewhere, please forgive me. But
also please post corrections! Also, may not be the most effecient way.)
:: First, to the branch. Just in case any other sticky tags, get rid of them
cvs up -A
cvs up -r ver_2_0
:: Look for any previous merges (maybe no cygwin, but Borland has grep ;-):
cvs tags | grep merge_ver_2_0_to_main
:: None, so start at 1
cvs tag merge_ver_2_0_to_main_1
:: Move to main branch
cvs up -A
:: do the merge
cvs up -j bp_merge_ver_2_0 -j merge_ver_2_0_to_main_1
:: do any conflict resolution and so forth
cvs commit -m "merged ver_2_0 from branch point to merge_ver_2_0_to_main_1"
So now we do some more fixups on the ver_2_0 branch and we go through the
process again:
cvs up -A
cvs up -r ver_2_0
cvs tags | grep merge_ver_2_0_to_main
:: output is:
merge_ver_2_0_to_main_1
:: so now we know we're at 2
cvs tag merge_ver_2_0_to_main_2
cvs up -A
cvs up -j merge_ver_2_0_to_main_1 -j merge_ver_2_0_to_main_2
cvs commit -m "merged ver_2_0 from merge_ver_2_0_to_main_1 to merge_ver_2_0_main_2"
Some things that could simplify this:
If no output from the grep, then just tag the branch point with
merge_ver_2_0_to_main_0 and then you can clean up the process a bit and
everythign with be in the form of _main_x to _main_{x+1}.
If anyone makes changes to the branch that should not be migrated over, one
could manually move the last checkpoint branch up past that change so it
doesn't move over next time.
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Tagging a sticky file?
On Fri, Apr 13, 2001 at 02:46:05PM -0500, David Luchin wrote: If I have a file in my repository with a sticky tag (NOT a branch), and Files in the in repository doesn't have sticky tags. Files in your workarea do. If you do something like: cvs update -r foo Then the sticky tag is placed on your harddrive and the repository couldn't care less. I add a tag, will that tag be associated with the sticky revision in my working area, or with the Repository revision? I want to keep the In your work area. If you use "tag" is always reference the version number of the file on your harddrive. Now, you may have uncommitted changes, and if you later commit those, the tag does not reflect that. It tags just the version of the file you last updated to. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Thu, Apr 12, 2001 at 11:05:51AM -0400, Noel L Yap wrote: If a wrapper tool were used, it would necessarily have to munge around the CVS/Entries file which is supposed to be internal to CVS (eg its implementation could change or it could disappear altogether in the future). Huh? I thought we were talking about a generic tool that would do a merge for any arbitrary file and save it to disk. What needs to use CVS/Entries? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Thu, Apr 12, 2001 at 11:29:59AM -0400, Noel L Yap wrote: [EMAIL PROTECTED] on 2001.04.12 11:14:55 I thought we were talking about a generic tool that would do a merge for any arbitrary file and save it to disk. What needs to use CVS/Entries? Should CVS be told about the merge? Ahhh. Ok. So there'd have to be some protocol that 3 files, and some sort of return code and CVS would handle marking up all of the Entries stuff (conflict, resolved status, appropriate time stamps, etc). mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 04:44:49PM -0400, Eric Siegerman wrote: Merging is very primitive Hmmm. How could it be better? NOT a rhetorical question; I'd really like to know. (I haven't used the commercial ones he's comparing CVS to.) I've recently started working at a perforce shop. One thing that perforce does with it's merging is, instead of doing a default merge, it gives you options: Keep your changes only, keep the other set of changes only, or merge the changes. Granted, in my experience, 99% of the time you want to merge the changes. But every once in a while, you don't. (and it's usually not determined by a file type so you can't use cvswrappers to control it). Otherwise, I've not been convinced that things like changesets where you pick and choose which bits and pieces get included into a particular source file (ala clearcase) is worth it. Just the administrative overhead would be obnoxious! :- One place I would like to see improvements is the ability to automatically be able to track how branches were synced up together so that changes aren't reapplied. Yes, this can be done easily with scripts. But having to write scripts portable to various environments is a bit of a pain (ie, making sure everyone has perl on their machines, or writing tools in Bourne and batch, and so forth). It's a tough selling point at times to say "Yes, we can easily work around that limitation, but we'll have to write a couple of extra tools." (Ignoring the fact that no matter what SCM tool we use, we're still going to have to write our own wrappers around it.) mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 06:06:22PM -0400, Eric Siegerman wrote: On Wed, Apr 11, 2001 at 02:27:15PM -0700, Mike Castle wrote: I've recently started working at a perforce shop. One thing that perforce does with it's merging is, instead of doing a default merge, it gives you options: Keep your changes only, keep the other set of changes only, or merge the changes. Not too hard to do in CVS once you know how. Granted, you have to take those steps *before* typing "cvs update"; it doesn't stop to ask you. (No, I'm not suggesting it should!) Oh, true. delete your file, or keep a backup copy of it before hand. But sometimes, if you know there is going to be this type of issue, that cvs would stop to ask you. But as I said, it's rare that you actually need that function, and probably not worth trying to code in. :- mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS bashing?
On Wed, Apr 11, 2001 at 05:21:26PM -0700, Paul Sander wrote: - The modules database isn't versioned, which can affect reproducibility requirements. This same problem exists with Perforce and it's concepts of 'views' (think each user has their own modules files). What we do is, instead of managing views (or modules) is copy code from the primary source into the heirarchy of the product, and then use it there. It's made read-only, and any changes that need to get made are done in the primary source tree only. (Changes will be automatically propogated out via use of triggers). This process should work with CVS as well. - The *info files accept a comprehensive list of sources on their command lines, limiting their scalability. (After a branch merge on a very large project, the command line buffer of the shell invoking the *info file can overflow, causing breakage.) I thought all of the *info files worked on subdirectory level only. You have enough files in a single directory to cause an overflow? :- This sounds like it could be somewhat easy to fix. Do something xargish inside of cvs to call them multiple times. - The history file grows without bound, and can't be managed in any natural way. A logrotate type of program can't work against history? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update gives P response
On Mon, Mar 26, 2001 at 09:33:43PM -0500, Chris Edgington wrote: server, I often get a P next to the filenames that are updated by cvs. What exactly is the P telling, in comparison to a U, M, or C? I don't find any documentation on the P response. I see in the source that it means that a Patch was sent and is only in the server build of CVS? Since we're using the client versions locally, I'm confused about why we're getting the P. Can anybody explain? The server was making effecient use of the network by sending only a patch across the wire instead of an entire new copy of the file. It determines the sizes of a patch and compares it against the size of the newest version. And then sends the smaller of the two. True, the server determines whether to send a patch or not. The client just applies it. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: using NFS from homogeneous (almost) systems
On Thu, Mar 22, 2001 at 01:02:25PM -0500, Frederic Brehm wrote: What are the pros and cons of using NFS to access the CVS repository between systems that are similar? What if the OS version isn't exactly the same? stability and speed are two issues. Even if you were 100% certain of your NFS client/server (just because they're the same doesn't mean they always work well together!) are robust, think about this: If you do a cvs diff -r 1.3 -r 1.8 somefile.c, if you are using NFS, your NFS client is going to have to traverse the file, extracting all the bits and pieces, and make the two temp files then do the diff on them. Where as, if you do it using client/server, then the server is going to do that work by accessing everything locally. Even if multiple people are doing that, the speed of local disks over NFS access is going to be the controlling factor. Just say no to NFS and just use :ext: with rsh or ssh. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: It is in the way
On Wed, Mar 14, 2001 at 07:01:22PM +0100, Francesc Guasch wrote: I'm looking for information about the error message "It is in the way" When it happens I have to remove the file and checkout again. I've been searching the docs and the web unsuccessfully. Where can I read about it ? This shouldn't happen. It's caused by a mismatch between the CVS/Entries file and the actual contents of the directory. Example: nexus@thune[11:47am]src/wine/wine(511) (ls -l ; cat CVS/Entries) | grep wine.ini -rw--- 1 nexususers4576 Nov 2 14:08 wine.ini /wine.ini/1.36/Thu Nov 2 22:08:47 2000// Are you using a file system that is not case senstive and tools that may change the case of files? If you see this, does the CVS/Entries file still have the file listed? Is your disk full where maybe the rewriting of the CVS/Entries file fails? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: add directory heirarchy
On Wed, Mar 14, 2001 at 02:11:42PM -0500, Derek R. Price wrote:
$ find newdir -type f -exec cvs add {} \;
This is the first command I've ever seen that works better with -exec vs
-print | xargs
(Ie, it won't work at all with -print | xargs)
mrc
--
Mike Castle Life is like a clock: You can work constantly
[EMAIL PROTECTED] and be right all the time, or not work at all
www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc
We are all of us living in the shadow of Manhattan. -- Watchmen
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update -jx -jy gives conflict on $Id$
On Thu, Mar 08, 2001 at 04:22:16PM -0800, Stephen Rasku wrote: That shouldn't apply in this case since he was attempting a merge of, apparently, a .c file. You can't merge binary files with CVS. cvs up -kk -jb1 -jb2 make make test test fails... hmmm. oh... broken binary file that wasn't part of the merge... oh damn cvs up -A make clean make make test Granted, not that big of a deal, but annoying. And does answer the question as to why one doesn't want to use -kk. It can also be a little slow having to rewrite all of your files when doing the -A. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs update: move away xyz; it is in the way
On Fri, Mar 09, 2001 at 11:41:09AM -0800, Chad Loder wrote: Hello. I'm getting inexplicable messages when updating my CVS sources: cvs update: move away foo.c; it is in the way where foo.c is a file that's still in the archive, whose sandbox version is up-to-date w.r.t. the repository version, and so on...I've never touched the thing. Is there still an entry for it in CVS/Entries? Perhaps that file got corrupt somehow? I saw some posts in the mail archives about this sort of thing, with some responses giving implausible explanations. :) I used to see it all the time on Win32 systems where people had two files of the same name but mixed case. :-/ What should I be looking at, if I really want to know what's causing this and how to stop it. Move the file out of the way, do an update, and then verify that they actually do have the same contents. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: update -jx -jy gives conflict on $Id$
On Thu, Mar 08, 2001 at 11:15:52AM -0800, Stephen Rasku wrote: Why is this a problem? You can always do "cvs update -A" after you have checked in your changes to get rid of the sticky tag. Because it mucks up binary files? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: merge/diff
On Fri, Mar 02, 2001 at 03:52:03PM -0700, Derek Scherger wrote: Is there any way to control the diffing done by cvs update -j so that it ignores whitespace differences? At the moment I'm reduced to manually applying the changes that cvs diff -bw sees rather than trying to fix up the conflicts caused by merging. Neither situation is particularly pleasant however! If you do a cvs diff -bw -u and then use patch, do you get fewer conflicts than using cvs straight forward? I know that in the past I had a situation where I could not get cvs to merge and had to resort to using the patch program externally after generating diffs in a slightly different manner. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: omitting binary files from import/update
On Wed, Feb 21, 2001 at 10:51:46AM +0900, Develop01 wrote: is there any simple command/flag for omitting binary (non-text) files from an import/update? -I mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: 2 how to in CVS questions
On Thu, Feb 15, 2001 at 09:06:20AM -0500, Mark O'Brien wrote: I am trying to figure out how to implement an automated process in which, just prior to checkin approval, the branch is verified. Then after checkin, the bug number is attached to that new file version. From reading your description of what you want to do, I was wondering something: How do you handle the situation where a particular bug fix may take several commits of the same file. That is, multiple revision numbers to one bug fix. I mean, the whole reason for having SCM is so that you can step back at any point of time. So, it may be that a particular bug fix may require the developer to perhaps step down the wrong path at some point at part of an investigation, and therefore back out some changes. So, without the ability to use the SCM, because it appears to be tied down to one version/bug fix, the developer is forced back to the old broken method of keeping their own backup copies of the files. Almost as bad as having no SCM in the first place! If you trust your developers enough to write code, then they should be smart enough to do something like add a line of comment to the commit message, like "BUG #123" and you could have something on the backend that will notice this in the message, and mark the bug as fixed in the bug tracking system. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs add --new
On Thu, Feb 15, 2001 at 12:28:18PM -0500, Mr. Aldo D. Longhi wrote: I like Rex's idea of creating a new way to add a new directory (and contents) to the repo. I do this all the time; "Import" is typically not what I want to do, and I haven't yet written a wrapper script to perform this sequence of actions so I end up doing it manually: I still can't see what the problem with import is. It's not like you really care about the version numbers assigned to the individual files, is it? After you do the import, then just start using it. The process works fine as that. Use yourself as the vendor. Also, why are you doing this "all the time?" If you are in the middle of switching from one SCM product to another, I could see where you would have to add a lot of new files to cvs at once. However, after that, files should be added as soon as they are created. So typically add at any given time, probably no more than 3 files at once: source, header, documentation. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: questions on cvs locking
On Thu, Feb 15, 2001 at 06:54:02PM -0500, Yuhe Liu wrote: We are using CVS for CM. It came with a problem that multiple developers were updating a same file. Although cvs provides lock/unlock commands, it seems not convenient. Well, CVS was designed to explicitly allow multiple developers to update the same file. So it is not a problem, it was a design goal. The idea is to let multiple developers update the same file, then merge their respective changes together. Obviously some file types don't work well for this, but text based stuff does. And cvs edit and company should be used for those files. What exact problems are you having? mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Remote repository
On Mon, Feb 12, 2001 at 07:51:53PM -, David Padilla wrote: I want to give a remote user the ability to access part of the source tree, and only that part. I know that I could make this section of the source tree a separate module, but I was wondering if there is another way. In other words: Sure. Run cvs in server mode over ssh, and use standard unix permissions. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Remote repository
On Mon, Feb 12, 2001 at 02:09:32PM -0800, David Padilla wrote: What are the access control lists? Where can they be found? I assumed operating system level ACL's. Built into the file system. So, would depends on what you're using. Something like AFS, most likely. I guess if running the server on NT (*shiver*), you could be using NT level ACL's. But, basically, something supported by your OS, rather than CVS. (No sense trying to have CVS reinvent the wheel, perhaps poorly). mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: can I use rtag to tag files in a branch
On Thu, Feb 08, 2001 at 08:07:00PM -, [EMAIL PROTECTED] wrote: The point of this is to be able to tag the branch from the mainline after doing a merge, and vice versa. This would be in order to support multiple merges with cvs update -j last-merge-point -j branch- name or -j HEAD. Since there is a race condition where someone coudl check in a file on the branch after you did the merge but before you tagged, I would recommend not trying to use rtag anyway. Instead, check out the branch you want to merge, tag there, then do the merge. mrc -- Mike Castle Life is like a clock: You can work constantly [EMAIL PROTECTED] and be right all the time, or not work at all www.netcom.com/~dalgoda/ and be right at least twice a day. -- mrc We are all of us living in the shadow of Manhattan. -- Watchmen ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
