simple usage question: `merge from current' operation
Suppose a project has to branches: the head is the current, development, release, and there is a stable branch, as well. Suppose I'm about to make a change which is supposed to go in both the head and the stable branch. What would be the easiest way to achieve this? Is there an idiomatic way to do it? If it's a single file, I could memorize the revision numbers and then do "cvs update -j1.42 -j1.43 foo.c". Or I could do "cvs update -p -r1.43 foo.c.new; mv foo.c.new foo.c". I'm sure there are more ways. tia, kai -- I like BOTH kinds of music. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Timezone info on NTFS drives...
Hi, Is it possible to verify partition type fox fixing NTFS file modification time ? After changing standart/daylight saving time CVS report all files as modified. P.S The same story with FAT 1 second difference due to 16bit timestamp in modified time ?? = Andrew G. Tereschenko Software Engineer Integrated Banking Information Systems [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
The way to do "locking" without breaking the CVS philosophy is through "cvs watch" and "cvs edit" (specially when using the "cvs edit -c" and "cvs ci -c" patches). To see who is "locking" files, use "cvs editors". This topic has been discussed numerous times and I still haven't seen an absolute need to use "cvs admin -l". Noel [EMAIL PROTECTED] on 2000.10.27 18:41:49 To: [EMAIL PROTECTED] cc: (bcc: Noel L Yap) Subject: locked files I asked this question a while ago, and know I have an answer. My colleagues complained on CVS because it's hard to know which files are locked by other people (yes we use the locking strategy). If someone wants to know how to get this information out of CVS, mail me. Regards, Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs This communication is for informational purposes only. It is not intended as an offer or solicitation for the purchase or sale of any financial instrument or as an official confirmation of any transaction. All market prices, data and other information are not warranted as to completeness or accuracy and are subject to change without notice. Any comments or statements made herein do not necessarily reflect those of J.P. Morgan Co. Incorporated, its subsidiaries and affiliates. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff generating unuseable patches ?
On Wed, Oct 18, 2000 at 05:59:06PM -0700, richard offer wrote: I'm trying to generate a large patch that includes new files [...] But for the new files it starts creating files called /tmp/cvsx instead of the files in the directory ? ie looking at the diff. Index: drivers/block/audit.c === RCS file: audit.c diff -N audit.c *** /dev/null Tue Aug 29 14:22:17 2000 --- /tmp/cvsQt9R2X Wed Oct 18 17:09:29 2000 CVS inserts the "Index:" line specifically so that this will work. Well, it used to work, until the following change was made to patch (this is an excerpt of a much longer ChangeLog entry): 1997-06-12 Paul Eggert [EMAIL PROTECTED] * pch.c: Ignore Index: line if either old or new line is present, and if POSIXLY_CORRECT is not set. So, you can make it work by setting POSIXLY_CORRECT in your environment when you apply the patch. Paul, just out of curiosity, can you still recall what this was about? Given that it breaks "gdiff -N"-generated patches (whether from CVS or otherwise), it must have been intended to fix something else. Any idea what? -- | | /\ |-_|/ Eric Siegerman, Toronto, Ont.[EMAIL PROTECTED] | | / Nobody ever got fired for buying Microsoft -- but they could get fired for relying on Microsoft. - Chris Garrigues ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
In search of merge scripts
A bunch of the hackers at my company are agitating for some better tools for managing the process of merging groups of changes from one branch to another. I've seen references on this list to scripts (shell, perl, or something) to aid (I don't want to say automate) the process of merging, when you've got, say, a mainline (devo) branch and a sustaining-engineering (release) branch. Any input appreciated. Thanks in advance. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
This topic has been discussed numerous times and I still haven't seen an absolute need to use "cvs admin -l". Well, some people don't trust that if someone gets a conflict when trying to merge, that the resulting file will be OK, because of human errors. Locking stalls development, but encourages that one person does some right without disturbance from others. Thomas ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -T option
Richard June wrote: Correct me if I'm wrong, but cvs -T /tmp update should store all the temporary files in /tmp as opposed to `pwd` correct? I'm using cvs v1.10.6 and the behaviour isn't like that, it is putting temp files in the current. if this is proper behaviour what variable should I be looking for in the source to change it? I doubt it. The default temporary directory is /tmp on unices. Are you referring to the .#* files? CVS leaves those scattered as backups of files with conflicts and they're left parallel to the conflicted parent file. It's intentional: http://cvshome.org/docs/manual/cvs_16.html#IDX469 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "Calm down. It's only ones and zeros." ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -T option
No, if I do a cvs update it downloads the file to the current directory as .file it has nothing to do with a conflict. I'm running out of space onthe device and I need them to d/l to /tmp instead On Mon, 30 Oct 2000, Derek R. Price wrote: Richard June wrote: Correct me if I'm wrong, but cvs -T /tmp update should store all the temporary files in /tmp as opposed to `pwd` correct? I'm using cvs v1.10.6 and the behaviour isn't like that, it is putting temp files in the current. if this is proper behaviour what variable should I be looking for in the source to change it? I doubt it. The default temporary directory is /tmp on unices. Are you referring to the .#* files? CVS leaves those scattered as backups of files with conflicts and they're left parallel to the conflicted parent file. It's intentional: http://cvshome.org/docs/manual/cvs_16.html#IDX469 Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- "Calm down. It's only ones and zeros." ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
Thomas Olausson wrote: This topic has been discussed numerous times and I still haven't seen an absolute need to use "cvs admin -l". Well, some people don't trust that if someone gets a conflict when trying to merge, that the resulting file will be OK, because of human errors. I don't trust people to do the right thing when merging manually. Given a shop of reasonable size and activity, somebody's going to be working on program X when it needs to be fixed Right Now. How are you going to handle that? CVS model: Make the quick fix, person doing the long-run development merges in the change, accounts for it, life goes on. Locking model: There are several possibilities. I've seen them. 1. Somebody makes the quick fix, by getting the program lock. Person doing the larger development keeps interim copy of program, and checks it back in without the quick fix. 2. Somebody makes the quick fix, and the person doing the larger development hand-merges it in incorrectly, creating a new bug. 3. Somebody makes the quick fix, and the person doing the larger development recreates the changes on top of the newly fixed version, inaccurately. 4. Quick fix is made and hand-merged in without program assistance. In a case like this, locking is useless. What you need in a case like this is communication. I've worked in a shop where we wrote "Please see me" on the listings in the listings books if we were going to make a change. That worked. We had less problems with conflicting changes than we did in the place where we used SCCS and locked. Locking stalls development, but encourages that one person does some right without disturbance from others. As long as you can guarantee a lack of disturbance, this works. I don't see that this is a realistic guarantee. When (not if) you have two conflicting changes to a file, often because it's being modified (and is not yet ready to use) and it needs a quick change, you need either communication or a reliable merge process. CVS' merge process isn't entirely reliable, but it's very good, and as long as people keep an eye on what's going on in programs they're working on it's a very good solution. CVS can also provide a means of communication, with its edit and watch facilities. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: locked files
this way seems like second guessing your programmers too much. By the same token someone could accidentally write a bug into a program even while normally changing it, but can you really account for it using the tool? Probably not...code reviews should be set up to prevent bad code from getting out onto the production system, and any bugs whether from merging incorrectly or from simple programming mistakes should be caught there. Does that make sense to anyone? =) Gary [EMAIL PROTECTED] Locking model: There are several possibilities. I've seen them. 1. Somebody makes the quick fix, by getting the program lock. Person doing the larger development keeps interim copy of program, and checks it back in without the quick fix. 2. Somebody makes the quick fix, and the person doing the larger development hand-merges it in incorrectly, creating a new bug. 3. Somebody makes the quick fix, and the person doing the larger development recreates the changes on top of the newly fixed version, inaccurately. 4. Quick fix is made and hand-merged in without program assistance. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -T option
1.5MB or so. that's perfectly fine if it's intentional, I just need it to behave differently. On Mon, 30 Oct 2000, Derek R. Price wrote: Then that's probably an atomic file update trick. The temp file is created, written to, and closed, then moved over the old file name. That this happens in the same working directory as the file being replaced is also intentional. Some platforms don't support mv's between partitions and '.' is fairly obviously going to be on the same partion as '.'. How tight is your disk space? This algorithm should never require more empty space than the size of the largest file in your workspace plus maybe the size a CVS/* file (e.g. CVS/Entries) or two. Derek -- Derek Price CVS Solutions Architect ( http://CVSHome.org ) mailto:[EMAIL PROTECTED] OpenAvenue ( http://OpenAvenue.com ) -- I will not sell miracle cures. I will not sell miracle cures. I will not sell miracle cures... - Bart Simpson on chalkboard, _The Simpsons_ ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: diff in commit message (was: Multiple-line log message)
On Sun, Oct 29, 2000 at 09:00 +0100, Gerhard Sittig wrote: There's a file /usr/src/contrib/cvs/FREEBSD-upgrade (if only I had the bookmark around with the web frontend to the FreeBSD source repo -- I can provide it on Tuesday) with the most important section for you at its end: http://www.freebsd.org/cgi/cvsweb.cgi/src/contrib/cvs/ virtually yours 82D1 9B9C 01DC 4FB4 D7B4 61BE 3F49 4F77 72DE DA76 Gerhard Sittig true | mail -s "get gpg key" [EMAIL PROTECTED] -- If you don't understand or are scared by any of the above ask your parents or an adult to help you. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -T option
On Mon, Oct 30, 2000 at 02:58:42PM -0500, Richard June wrote: 1.5MB or so. that's perfectly fine if it's intentional, I just need it to behave differently. Delete the file that's being updated, then do an update. 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: -T option
Not an option, this is scripted, only have a little bit of free space, and I need cvs to not write scratch files into the working directory. It doesn't improve anything that For the most part I'm dealing with binary files. On Mon, 30 Oct 2000, Mike Castle wrote: On Mon, Oct 30, 2000 at 02:58:42PM -0500, Richard June wrote: 1.5MB or so. that's perfectly fine if it's intentional, I just need it to behave differently. Delete the file that's being updated, then do an update. 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS diff generating unuseable patches ?
* $ from [EMAIL PROTECTED] at "30-Oct: 9:56am" | sed "1,$s/^/* /"
*
*
* On Wed, Oct 18, 2000 at 05:59:06PM -0700, richard offer wrote:
* I'm trying to generate a large patch that includes new files
* [...]
* But for the new files it starts creating files called /tmp/cvsx instead
of
* the files in the directory ?
*
* ie looking at the diff.
*
*
* Index: drivers/block/audit.c
* ===
* RCS file: audit.c
* diff -N audit.c
* *** /dev/null Tue Aug 29 14:22:17 2000
* --- /tmp/cvsQt9R2X Wed Oct 18 17:09:29 2000
*
* CVS inserts the "Index:" line specifically so that this will
* work. Well, it used to work, until the following change was
* made to patch (this is an excerpt of a much longer ChangeLog
* entry):
* 1997-06-12 Paul Eggert [EMAIL PROTECTED]
* * pch.c: Ignore Index: line if either old or new line is present, and
if
* POSIXLY_CORRECT is not set.
*
* So, you can make it work by setting POSIXLY_CORRECT in your
* environment when you apply the patch.
Tried that, it still didn't work as expected (it failed in a different but
worse way---but I can't remember the details).
My problem is that fixing patch is not going to help me. It would mean that
everybody that wants to apply my code change will need to upgrade their version
of patch.
Given that rdiff does generate useablem shouldn't diff just use the same
logic/code ?
richard.
---
Richard Offer Widget FAQ -- http://reality.sgi.com/widgetFAQ/
{X,Motif,Trust} on {Irix,Linux}
__http://reality.sgi.com/offer/
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Starting New Repository - Vendor Branch - Bug/Feature? (was: CVS IMPORT Help)
The following message is a courtesy copy of an article that has been posted to gnu.cvs.help as well. "Fred W." [EMAIL PROTECTED] writes: Prior to making changes I want to tag the current version as 'REL_1_0 ' . Assume I only have one file 'test.txt'. When I look at the log it shows the tag on 1.1.1.1 of the file. How can I tag version 1.1? I have a related question that I think will answer and clarify the above. I am a fairly experienced CVS user, but only recently understood the basic concept behind the Vendor Tag/Branch and the main trunk when you first import an existing set of source files. In effect, the initial Vendor Tag specifies a branch with revision number 1.1.1 containing files all of revision 1.1.1.1. These are IDENTICAL to the initial files (all at revision 1.1) on the main trunk. My question concerns the information returned by "status" after the first checkout of a newly created repository. In another directory and shell, I created a new reposity with: lonestar(349)$ cvs -d sswift@calvin:/Repository import -m "Import of the Gent Cane Ocean Model" Applications/Gent_Cane code970 GentCane_v1. I then checked out the first copy of the new repository (against which no changes have made yet). The files should be on the main trunk and there should be one branch and tag for the vendor branch. If I do a "status" on any of the files, I see output like this: lonestar(11)$ cvs status -v wdrivn.f === File: wdrivn.f Status: Up-to-date Working revision:1.1.1.1 Repository revision: 1.1.1.1 /Repository/Applications/Gent_Cane/src/wdrivn.f,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: GentCane_v1 (revision: 1.1.1.1) code970 (branch: 1.1.1) Why does CVS report that my working revision is 1.1.1.1? Is that a bug or a feature? Shouldn't it say 1.1? I understand (I believe correctly) that there is no text difference between the files at revision 1.1 and 1.1.1.1, but it would seem more clear and accurate to report that my working files are on the trunk, since that appears to be where any modifications I make will be placed. My CVS version is 1.10 under IRIX 6.5.7f. A quick check with CVS 1.11 on the same system shows the same behavior. The repository was created with CVS 1.10. Now if I modify a file and check it in, I see behavior like I expect: lonestar(12)$ cvs update cvs server: Updating . M wdrivn.f lonestar(13)$ cvs ci -m "Test of vendor branching function" wdrivn.f Checking in wdrivn.f; /Repository/Applications/Gent_Cane/src/wdrivn.f,v -- wdrivn.f new revision: 1.2; previous revision: 1.1 done lonestar(15)$ cvs status -v wdrivn.f === File: wdrivn.f Status: Up-to-date Working revision:1.2 Repository revision: 1.2 /Repository/Applications/Gent_Cane/src/wdrivn.f,v Sticky Tag: (none) Sticky Date: (none) Sticky Options: (none) Existing Tags: GentCane_v1 (revision: 1.1.1.1) code970 (branch: 1.1.1) The new revision is 1.2 (on the main trunk) as I expect and want. However, note that the output says the previous revision was 1.1! There were no intervening commands issued here, so why does the "status" report and the "check in" not report the same version information? That seems like a small bug to me. But it did make me pause and investigate for a day because I thought the repository had a problem. Perusing the FAQ included in v. 1.11, I found this comment discussing the differences between RCS and CVS branches: "Only CVS moves the RCS default branch on first commit." If this means the above situation is a feature, I think it is worth noting in the Info file discussion of branches and importing to avoid confusing users. I believe this suggests the answer to the original post is that if he makes a tag on the working version of his files, it will be applied to the trunk and not the vendor branch. I did not test this, it is just an hypothesis. Any comments would be appreciated. Spencer __ Spencer Swift ([EMAIL PROTECTED])/ ___/\ Silicon Graphics, Inc. /___ /\/__ NASA/GSFC, Building 28, Rm. S230 /_/ // ___/\ Code 931 \_\// / /\/__ Greenbelt, MD 20771 /_/ //_ __/\ \_\/_\/ /__\/ WK: (301) 286-2829 /_/\ FAX (301) 286-1634 \_\/
access rights to branches
Hi, I have a CVS user who continues to checkout modules or update files from the wrong branches. Can I restrict her ability to update from particular branches or main trunk? The only thing I can find about access rights with CVS is to do with Unix file permission this is fine if you want to stop someone from accessing a project, but not enough if you just want to restrict access to a particular branch in the project. Any help much appreciated (she's driving me nuts!!! ;) Shem ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: -T option
On Mon, Oct 30, 2000 at 04:24:46PM -0500, Richard June wrote: Not an option, this is scripted, only have a little bit of free space, and I need cvs to not write scratch files into the working directory. It doesn't improve anything that For the most part I'm dealing with binary files. Well, what other options do you have? CVS does not, as far as I know, do an update directly into the filename. It updates, deletes old, renames new. But what does scripting it have to do with not being able to delete the file and then update it? You are already apparently not concerned with having a transient state where the file isn't there in a complete form. So what's the problem? Just do a cvs -n up, gather up the list of files that need to be updated, loop over deleting them and then doing a true update on each file. 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: -T option
Here's the deal, I have limited space(1.5MB free on a 14MB partition, filenames that change, so stuff gets deleted and added as opposed to just patched, not that it would matter anyway, most of the files are binary. I don't care about the transient state, only that the final file is intact. All I want is to make CVS download stuff to /tmp/.filename instead of ./.filename I've been looking at it but I've not quite gotten my mind around the section of code I think does it. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
