RE: Merging in CVS
From my experience, technically the way CVS performs merges is fine. The biggest problem has been misunderstanding of how to correctly perform a merge, and this is a problem you can have with any tool. I've had instances where someone complained that CVS screwed up a merge, but when I dug a little deeper, it turned out the user had made the mistake, not the tool. There are some holes in CVS (e.g., directory versioning), but overall it's a very easy tool to use and manage, even with a large number of users. Dave -Original Message- From: MacMunn, Robert [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 12:54 PM To: 'Thomas S. Urban' Cc: [EMAIL PROTECTED] Subject: RE: Merging in CVS We have 3 CM tools within the whole comapny. CVS, Perforce, and Clearcase. Management wants to go with 1 tool. They feel Clearcase is too expensive, and it can be. I am a Clearcase guy, but know the cost. So, Perforce seems limited, CVS seems to be able to handle all that we need. I just need to make sure that there aren't any gotcha's. From the feedback I am getting from other CVS users is that CVS handles merges poorly. I am not here to start an arguement on which is the better CM tool. I am not closed minded to think that because I know Clearcase, that it is the best tool. I am trying to find out where we may have problems with release engineering and developers. The graphical merge tool Clearacse has saves a lot of time, and it is part of Clearcase. The cost of Clearcase is just too astronomical now and like I said CVS seems to have all that we need. I am just trying to figure out what we gain and what we lose. -Original Message- From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:39 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: Re: Merging in CVS So use Clearcase if it provides something you can't live without. I'm only trying to point out that logically, the operations are the same (the timing may be a little different), e.g: 1 You request an update of local file to newest version in repository 2 CVS will merge new version and local changes (if any) automatically, (if possible) 3 If automatic merge is not possible, CVS forces user to *manually* resolve conflicts If you can show my how clearcase behaves differently than this *logically*, then maybe you've got a point (and maybe I'll start using clearcase since it would then have the ability to read my mind). Everthing else is just interfaces and easy of use, both of which are qualities easy to remedy through toolsmithing, IMO. On Fri, Nov 22, 2002 at 13:28:02 -0500, MacMunn, Robert sent 3.0K bytes: It isn't a slick interface. In Clearcase it is the merge tool itself that gives you the ability to deal with the conflicts easily. -Original Message- From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:27 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: Re: Merging in CVS On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K bytes: Not at all. In Clearcase you have a graphical interface where the conflicts can be taken care of as the merge happens. No manual editting of files. A nice tool with a graphical interface is still a manual tool. It may be easier to use than a simple text editor (but why would you use a simple text editor?), but both process are manual versus automatic. Perhaps the time the manual work happens is significant, I don't know, but it still happens. Graphical interfaces for dealing with the conflict markers CVS produces probably exist, either with one of the many GUI clients, or with emacs. The vim plugin I use highlights them specially. If I cared, I could write easy vim functions that would take one version or the other for each conflict. But it rarely comes up in our usage (i.e. including good communication), so I don't care all that much about slick interfaces to conflict resolution. -Original Message- From: Thomas S. Urban [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:16 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: Re: Merging in CVS On Fri, Nov 22, 2002 at 12:23:56 -0500, MacMunn, Robert sent 0.9K bytes: Thanks. Looks like merges must be difficult in CVS. A lot of manual work. Most of the time, merges happen automatically. Manual intervention is only required when they can't happen automatically. Conflicts always take (some amount) of a manual work. Merges never do. I don't see how you can get around this fact in any system, short of exclusivity. Looks like you may be confused by terminology. RTFM. HTH Scott -Original Message- From: Kaz Kylheku [mailto:[EMAIL
RE: Merging in CVS
The replacement he's referring to is Subversion. I don't think it's quite ready for prime time, but it looks like it will be very nice. Dave -Original Message- From: MacMunn, Robert [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:54 PM To: Daniels, Dave F [PCS] Cc: [EMAIL PROTECTED] Subject: RE: Merging in CVS It is looking that way to me also and you can't beat the price. A friend of mine was at the Apache conference this week and says there is a replacement coming out for CVS. -Original Message- From: Daniels, Dave F [PCS] [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 2:43 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: RE: Merging in CVS From my experience, technically the way CVS performs merges is fine. The biggest problem has been misunderstanding of how to correctly perform a merge, and this is a problem you can have with any tool. I've had instances where someone complained that CVS screwed up a merge, but when I dug a little deeper, it turned out the user had made the mistake, not the tool. There are some holes in CVS (e.g., directory versioning), but overall it's a very easy tool to use and manage, even with a large number of users. Dave -Original Message- From: MacMunn, Robert [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 12:54 PM To: 'Thomas S. Urban' Cc: [EMAIL PROTECTED] Subject: RE: Merging in CVS We have 3 CM tools within the whole comapny. CVS, Perforce, and Clearcase. Management wants to go with 1 tool. They feel Clearcase is too expensive, and it can be. I am a Clearcase guy, but know the cost. So, Perforce seems limited, CVS seems to be able to handle all that we need. I just need to make sure that there aren't any gotcha's. From the feedback I am getting from other CVS users is that CVS handles merges poorly. I am not here to start an arguement on which is the better CM tool. I am not closed minded to think that because I know Clearcase, that it is the best tool. I am trying to find out where we may have problems with release engineering and developers. The graphical merge tool Clearacse has saves a lot of time, and it is part of Clearcase. The cost of Clearcase is just too astronomical now and like I said CVS seems to have all that we need. I am just trying to figure out what we gain and what we lose. -Original Message- From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:39 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: Re: Merging in CVS So use Clearcase if it provides something you can't live without. I'm only trying to point out that logically, the operations are the same (the timing may be a little different), e.g: 1 You request an update of local file to newest version in repository 2 CVS will merge new version and local changes (if any) automatically, (if possible) 3 If automatic merge is not possible, CVS forces user to *manually* resolve conflicts If you can show my how clearcase behaves differently than this *logically*, then maybe you've got a point (and maybe I'll start using clearcase since it would then have the ability to read my mind). Everthing else is just interfaces and easy of use, both of which are qualities easy to remedy through toolsmithing, IMO. On Fri, Nov 22, 2002 at 13:28:02 -0500, MacMunn, Robert sent 3.0K bytes: It isn't a slick interface. In Clearcase it is the merge tool itself that gives you the ability to deal with the conflicts easily. -Original Message- From: 'Thomas S. Urban' [mailto:[EMAIL PROTECTED]] Sent: Friday, November 22, 2002 1:27 PM To: MacMunn, Robert Cc: [EMAIL PROTECTED] Subject: Re: Merging in CVS On Fri, Nov 22, 2002 at 13:17:12 -0500, MacMunn, Robert sent 1.7K bytes: Not at all. In Clearcase you have a graphical interface where the conflicts can be taken care of as the merge happens. No manual editting of files. A nice tool with a graphical interface is still a manual tool. It may be easier to use than a simple text editor (but why would you use a simple text editor?), but both process are manual versus automatic. Perhaps the time the manual work happens is significant, I don't know, but it still happens. Graphical interfaces for dealing with the conflict markers CVS produces probably exist, either with one of the many GUI clients, or with emacs. The vim plugin I use highlights them specially. If I cared, I could write easy vim functions that would take one version or the other for each conflict. But it rarely comes up in our usage (i.e. including good communication), so I don't care all that much about slick interfaces
problem commiting file to CVSROOT
I have several files I'm trying to commit to a subdirectory of CVSROOT, but only the ,v file is being created. I'm concerened about this because some users may make changes without realizing the files aren't being updated correctly on the server. To work around this problem temporarily, I've manually created the necessary files on the server, but I'd like to understand why this isn't being done by cvs. -I'm trying to import files to CVSROOT/commitmessage/filename -These files appear to import correctly, but only the ,v file is created on the server. -I have successfully imported other files to this directory. -The files appear to be valid from the client. -The checkoutlist file contains entries for the files that are being imported correctly, but not for those that aren't. I tried to manually add the ones not working, then make a change and commit, but my manual entries were removed after the commit. -I've had this problem with (I think) the same files on two separate servers. Any help would be greatly appreciated. Thanks, Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
capture branch name with loginfo
Is it possible to capture the branch information for an email created from a loginfo script? I'd like to include the branch a change was made to, not just the module. Thanks, Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem commiting file to CVSROOT
-I'm trying to import files to CVSROOT/commitmessage/filename One generally adds files to an existing directory rather than importing them. That's what I'm doing. Please don't get hung up on semantics. I tried to manually add the ones not working, then make a change and commit, but my manual entries were removed after the commit. checkoutlist is version controlled -- you need to check it out, make your changes, and commit it. If you just checkout the entire CVSROOT directory, you can make the necessary additions to checkoutlist, add your new files, and commit everything at once. D'oh! This solved the problem. The real issue was my understanding. Thanks for your help. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: problem commiting file to CVSROOT
I am not new to CVS. When I say 'users', I mean future administrators who may not be aware there's a problem. I'm familiar with the sections you referenced, but my problem is not addressed there (or anywhere else I can find.) I'm not talking about normal source files, I'm talking about administration scripts used to send email notifications. The checkoutlist issue may be a red herring, for all I know, but it seemed odd. I'm trying to understand why the cvs server created a ,v file but not a normal file for certain files I checked into CVSROOT as an administrator but had no problem with other files. Dave -Original Message- From: Todd Denniston [mailto:Todd.Denniston;ssa.crane.navy.mil] Sent: Friday, November 01, 2002 9:20 AM To: Daniels, Dave F [PCS] Cc: [EMAIL PROTECTED] Subject: Re: problem commiting file to CVSROOT Daniels, Dave F [PCS] wrote: I have several files I'm trying to commit to a subdirectory of CVSROOT, but only the ,v file is being created. I'm concerened about this because some users may make changes without realizing the files aren't being updated correctly on the server. To work around this problem temporarily, I've manually created the necessary files on the server, but I'd like to understand why this isn't being done by cvs. if you are talking about files in $CVSROOT/CVSROOT/ (admin files) http://www.cvshome.org/docs/manual/cvs_2.html#SEC20 then you are probably looking for: http://www.cvshome.org/docs/manual/cvs_18.html#SEC176 In this case I have to ask, Why are USERS changing any thing in this directory? The users question is why I am confused as to what you are asking. if you are new to cvs, I am concerned you are talking about normal files (source code)? here I would suggest reading most of the manual http://www.cvshome.org/docs/manual/ but in particular http://www.cvshome.org/docs/manual/cvs_2.html#SEC9 and http://www.cvshome.org/docs/manual/cvs_2.html#SEC11 -- I'd crawl over an acre of 'Visual This++' and 'Integrated Development That' to get to gcc, Emacs, and gdb. Thank you. -- Vance Petree, Virginia Power ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Can I check out a file without specifying the module it's in?
It should be pointed out that this requires access to the server the CVS repository is on. I don't believe there's a way to do this with the CVS client. -Original Message- From: Zieg, Mark [mailto:mark.zieg;lmco.com] Sent: Thursday, October 31, 2002 11:50 AM To: '[EMAIL PROTECTED]'; '[EMAIL PROTECTED]' Subject: RE: Can I check out a file without specifying the module it's in? 1. Is there a way to checkout a file without knowing exactly which module it's in? find $REPOSITORY -name fooglitz.c I realize that this could lead to problems if there are (for some lame reason) multiple fooglitz.c files, but let's forget about that possibility right now. That's not exactly a lame scenario. You'll find an awful lot of modules -- and directories within a single module -- containing files like Makefile, main.c, README, index.html, etc. 2. Is there a way to make the checkout non-case-specific? find $REPOSITORY | grep -i fooglitz.c ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
controlled files to be deployed to different environments
For one of my projects I have a configuration file, say mail.properties, which I'm versioning in CVS. The contents of this file will be different for different environments, though. For example, the mail server for my development environment is different than for my production environment. Currently, I have the development version controlled, and when my project is ready for deployment to production, I manually change the contents and send it off (but don't change the version in CVS). I would like suggestions on ways to control different versions of the same file. So far, the best idea we've come up with is to give each version a different extension and then use our make utility to pull the right one and rename it, so email.properties.dev becomes email.properties. Any other suggestions? Thanks, Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: CVS version control cold fusion
Sure, why not? Cold Fusion files are simply text files, and CVS handles text files very well. Dave -Original Message- From: Gail Milton [mailto:[EMAIL PROTECTED]] Sent: Wednesday, May 29, 2002 2:38 PM To: info-cvs Subject: CVS version control cold fusion Hello, I'm trying to find out if CVS 'works plays well' with cold fusion. We have an application written in cold fusion that this currently stored in PVCS. However, PVCS doesn't 'play well' with cold fusion and corrupts/changes the code when retrieved from PVCS. Needless to say, this is causing major problems. Any information you can provide concerning CVS and how it handles cold fusion will be most appreciated. Thank you, Gail ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
problems merging from branch to mainline
Hi, I'm having some trouble merging from a branch to the mainline. The latest branch version is 1.1.2.9, while the latest mainline version is 1.2. I'm running this command from a checked-out copy of the mainline: cvs update -j1.1.2.9 foo.jsp What I expected to happen was file 'foo.jsp' would be updated from the changes in 1.1.2.9, which I would turn around and commit. Instead, I get the message: cvs server: file foo.jsp exists, but has been added in revision 1.1.2.9 How to I merge my changes from my branch to the mainline in this case? Thanks, Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs prune question
Hi, When updating a module using the command 'cvs update', CVS prints lines which look something like this. M project/src/com/company/Test1.java M project/src/com/company/Test2.java P project/src/com/company/Test3.java I know the M means merge, and I suspect the P means prune. Can someone confirm that for me? If that's true, why is it performing this action without the -P switch, and what does it mean in this context? Thanks for your help, Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
