Re: cvs branch version
Hi, I used 'cvs tag' to add a file to a branch. I then used 'cvs commit -r... ' to check in a new version. It normally creates a subversion from the version initially tagged. For example, I tag file 'A' version 1.1 with release-patch. It creates a version 1.1.0.2 for the tag. When I check in a new version to the branch, it creates a version 1.1.2.1. But this time, I did not see any output from the command line after I entered the comments in vi. When I did a 'cvs log', I did not see any subversion created. Did you change the file before committing it? CVS will not create a new revision unless there are changes from the old one. If I do a 'cvs status' on the file, the sticky tag shows : Sticky Tag: release-patche (branch: 1.1.2) But I cannot see this revision with 'cvs log'. Can anyone explain what happened? Sure. You now have the file in your working area as branch 1.1.2, but since there is no change from the original version, the only revision is 1.1. This revision is on both the trunk and the branch right now. That's what it looks like to me. David H. Thornley| If you want my opinion, ask. [EMAIL PROTECTED] | If you don't, flee. http://www.thornley.net/~thornley/david/ | O- ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Renaming a branch
David Leskovac writes: Okay. So, just to be clear, this is actually a 3-step process: 1. Checkout branch: cvs co -r branchname module 2. Rename from sandbox: cd to root of module in sandbox cvs admin -n newname:oldname 3. Delete original tag name sandbox: cd to root of module in sandbox cvs tag -d oldname Correct? Correct. I strongly encourage you to verify that step 2 has worked correctly before you move on to step 3, though. :-) Thanks to all for the responses on this. Last question(s): If the cvs admin -n command renames branches why the need to delete the original branch name? What happens if you don't delete the original name? -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Renaming a branch
You still need a 2-step process, you just use admin -n to create a new name for the existing branch rather than using tag -b to create a new branch: cvs admin -n newname:oldname cvs tag -d oldname (Note that there's no radmin command so you need to have a checked out working directory.) Okay. So, just to be clear, this is actually a 3-step process: 1. Checkout branch: cvs co -r branchname module 2. Rename from sandbox: cd to root of module in sandbox cvs admin -n newname:oldname 3. Delete original tag name sandbox: cd to root of module in sandbox cvs tag -d oldname Correct? -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Renaming a branch
Would this work for each branch to be renamed?: cvs rtag -b -r original_branch_name new_branch_name module No, that creates a new branch off of the existing branch rather than renaming the existing branch. You need to use admin -n instead. Okay. So rather than the 2-step process I mentioned in my original post where I would create a new branch from the original branch then delete the original branch, there is a way to simply rename the existing branch with a cvs admin -n command? I looked at the syntax of cvs admin but it is not clear to me how this can be achieved. Would someone please provide an example? Thanks, -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Continuous Integration with CVS
Is any one doing Continuous Integration with CVS ? Yes. We use CruiseControl 2.2.1 -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Nooby question: need help with setting CVSROOT=/usr/local/cvs-rep
It's working just as designed. :-) Variables that stay around permanently only stay that way as long as you are logged in. I suggest adding it to your .bashrc file in your home directory. UNIX/Linux process that file every time a new terminal session is opened and will set it automatically at that time as a part of your profile setup. You may also want to consider adding the variable to: /etc/profile or /etc/bashrc to make $CVSROOT available to all users - if you have permission to edit those files. -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
Hi,
Well, I've had a crack at implementing the optimisation; and attached
is a patch which seems to work - but there is at least one nasty
hack in it; more about that in a sec.
To enable it you need to add:
TagOverwriteEnable=yes
to the config file in the CVSROOT; without that it should not
change behaviour in any way (except adding that as a commented
out option with warning to a newly created repository).
It won't give you any performance benefit on the first tag, but should
give something on subsequent tags. I see some improvement (~15%)
but it is variable, on a large repository that doesn't fit in
memory on my home machine.
It is my first dig into the CVS code base, so I would appreciate
(gentle) comments.
Now some details;
1) The real nasty hack; this is something that I hadn't thought
of (and I don't think anyone else noticed?) in my original
description; the permissions on the rcs files is read only
so when I need to open them to overwrite I can't - this is a pain;
this patch has a gratuitous (and obviously WRONG) hack in of
chmod'ing it before the open - I'm open for any suggestions *if*
there is a right way of doing this. (This was a pain because
it was at the very last stage of the patch that I noticed this!).
2) I don't currently create the dummy ,foo, locking file.
3) I haven't written any docs yet.
4) I needed to get a couple of values out of rcsbuf_getkey and
have shoved them in globals for the moment; I was looking for a
neater way that wouldn't mean changing all the callers.
5) I'm worried about the right types to use for file offsets
in a portable way. (Has anyone tried cvs with rcs files over 2GB?)
The patch is against 1.12.9 which is the version my debian happened to
have.
As I say, suggestions - and experiences welcome.
Dave
-Open up your eyes, open up your mind, open up your code ---
/ Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \
\ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex /
\ _|_ http://www.treblig.org |___/
diff -ur orig/cvs-1.12.9/ChangeLog cvs-1.12.9/ChangeLog
--- orig/cvs-1.12.9/ChangeLog 2004-06-09 15:52:32.0 +0100
+++ cvs-1.12.9/ChangeLog2005-03-24 23:43:48.0 +
@@ -1,3 +1,6 @@
+2005-03-24 Dave Gilbert [EMAIL PROTECTED]
+ * Added fast tagging mechanism; rcs.h/c, parseinfo.c,mkmodules.c
+
2004-06-09 Derek Price [EMAIL PROTECTED]
* NEWS: Note Stefan Sebastian's security fixes.
diff -ur orig/cvs-1.12.9/src/admin.c cvs-1.12.9/src/admin.c
--- orig/cvs-1.12.9/src/admin.c 2004-03-22 15:37:34.0 +
+++ cvs-1.12.9/src/admin.c 2005-03-27 20:39:38.0 +0100
@@ -792,7 +792,7 @@
|| (rev = RCS_tag2rev (rcs, p))) /* tag2rev may exit */
{
RCS_check_tag (tag); /* exit if not a valid tag */
- RCS_settag (rcs, tag, rev);
+ RCS_settag (rcs, tag, rev, NULL);
free (rev);
}
else
diff -ur orig/cvs-1.12.9/src/commit.c cvs-1.12.9/src/commit.c
--- orig/cvs-1.12.9/src/commit.c2004-06-09 15:52:37.0 +0100
+++ cvs-1.12.9/src/commit.c 2005-03-27 20:39:45.0 +0100
@@ -2144,7 +2144,7 @@
head = RCS_getversion (rcs, NULL, NULL, 0, (int *) NULL);
magicrev = RCS_magicrev (rcs, head);
- retcode = RCS_settag (rcs, tag, magicrev);
+ retcode = RCS_settag (rcs, tag, magicrev, NULL);
RCS_rewrite (rcs, NULL, NULL);
free (head);
diff -ur orig/cvs-1.12.9/src/import.c cvs-1.12.9/src/import.c
--- orig/cvs-1.12.9/src/import.c2004-04-27 22:08:40.0 +0100
+++ cvs-1.12.9/src/import.c 2005-03-27 20:39:59.0 +0100
@@ -770,7 +770,7 @@
if (noexec)
return (0);
-if ((retcode = RCS_settag(rcs, vtag, vbranch)) != 0)
+if ((retcode = RCS_settag(rcs, vtag, vbranch, NULL)) != 0)
{
ierrno = errno;
fperrmsg (logfp, 0, retcode == -1 ? ierrno : 0,
@@ -792,7 +792,7 @@
vers = Version_TS (finfo, NULL, vtag, NULL, 1, 0);
for (i = 0; i targc; i++)
{
- if ((retcode = RCS_settag (rcs, targv[i], vers-vn_rcs)) == 0)
+ if ((retcode = RCS_settag (rcs, targv[i], vers-vn_rcs, NULL)) == 0)
RCS_rewrite (rcs, NULL, NULL);
else
{
diff -ur orig/cvs-1.12.9/src/mkmodules.c cvs-1.12.9/src/mkmodules.c
--- orig/cvs-1.12.9/src/mkmodules.c 2004-05-29 05:48:52.0 +0100
+++ cvs-1.12.9/src/mkmodules.c 2005-03-24 23:43:38.0 +
@@ -349,6 +349,23 @@
# Be warned that these strings could be disabled in any new version of
CVS.\n,
UseNewInfoFmtStrings=yes\n,
#endif /* SUPPORT_OLD_INFO_FMT_STRINGS */
+# Options relating to the Tag overwrite optimisation\n,
+# ** WARNING ** Only enable this after reading the appropriate
documentation\n,
+# since it can cause
Re: Idea for reducing disk IO on tagging operations
* Doug Lee ([EMAIL PROTECTED]) wrote: I followed this discussion only loosely and kept silent because I suspect someone will shoot me to pieces for the complaint I'm about to make, but now that we're to the stage of actual implementation, I guess I'd like to say this anyway... Hey that's OK. I have reservations about any system that makes whitespace significant in a text file. I can make an exception for indent levels, as used by Python, because these are visible and errors are obvious without resorting to odd tactics like hex editors, vi's :list command, etc. Let me make it clear that this patch *in no way* makes whitespace significant; in actual fact it only works because it isn't significant. What it does is put a glob of whitespace in when it is convenient; nothing changes in the parsing or anything - so just like before that whitespace is completely ignored. The trick is that when it comes to add a tag it checks to see if there is spare white space and if so overwrites it; if you removed the white space or otherwise fettled with the file that is fine; it won't perform the optimisation. Indeed this means that an existing cvs client can quite happily read a repository which has had my patch inflicted on it. (The existing cvs code that rewrites the file will remove any excess white space you added up there anyway.) Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
* Jim Hyslop ([EMAIL PROTECTED]) wrote: Dr. David Alan Gilbert wrote: 2) I could do with a better under standing of the directory locks; pointers? I've read the top of lock.c but it still doesn't tell me enough; for example there seem to be multiple lock files used - but then surely the creation of them isn't atomic? Or is there one lock file used for both reading and writing? The locking process is explained in the manual, at https://www.cvshome.org/docs/manual/cvs-1.11.19/cvs_2.html#SEC17 Thanks Jim for pointing me at that (I'd had a good search through the FAQ rather than the manual). (and to Paul - apologies if I misquoted in that last email) OK; this convinces me that I don't need to worry about cvs reading my file while it is being modified. Together with the restriction of me only performing my trick if the write is entirely within a block then I feel reasonably safe. I'm going to have a crack at making this optimisation and will forward a copy here for discussion when I've done it. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
* Mark D. Baushke ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Sander [EMAIL PROTECTED] writes: Actually, if you look closely, I believe that CVS will not do read-only RCS operations if a CVS write-lock exists for the directory. Of course, ViewCVS and CVSweb do it all the time as do many of the other add-ons. I'm getting more worried about this one for 2 seperate reasons: 1) There is talk of cvs -n for diff and the like which seems to suggest it ignores locks. 2) I could do with a better under standing of the directory locks; pointers? I've read the top of lock.c but it still doesn't tell me enough; for example there seem to be multiple lock files used - but then surely the creation of them isn't atomic? Or is there one lock file used for both reading and writing? There's also the interrupt issue: Killing an update before it completes leaves the RCS file corrupt. You'd have to build in some kind of crash recovery. But RCS already has that by way of the comma file, which can simply be deleted. Other crash recovery algorithms usually involve transaction logs that can be reversed and replayed, or the creation of backup copies. None of these are more efficient than the existing RCS update protocol. Agreed. This is a very big deal. Actually I'm becoming less worried by this; I'm failing to see any way that a single system call write() to a block not crossing a block boundary could partially fail; but I'm up for suggestions. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Idea for reducing disk IO on tagging operations
Hi, I maintain a system that is used to hold a rather large CVS repository (~1GB give or take) which could do with being faster. Tagging in particular is slow and I don't think cpu or ram is the issue (it is a dual xeon with 3GB of RAM). My suspicion is that at least one of the problems is that when a tag is added most of the rcs files are rewritten giving a sudden large amount of data that must be written to disc. So - here are my questions/ideas - I'd appreciate comments to tell me whether I'm on the right lines: 1) As I understand it the tag data is the first of the 3 main data structures in the RCS file (tag, comments, diffs) and that when I do pretty much any CVS operation I rewrite the whole file - is this correct? 2) White space appears to be irrelevent in RCS files; so adding arbitrary amounts in between sections should leave files still fully compatible with existing RCS/cvs tools. 3) So the idea is that when I add a tag I add a bunch of white space after the tag (lets say 1KB of spaces split into 64 byte lines or similar); when I come to add the next tag I check if there is plenty of white space, if there is then instead of rewriting the file I just overwrite the white space with my new tag data; if there is no space then as I rewrite the file I add another lump of white space. 4) Whether dummy white space is added and how much is controlled by the existing size of the RCS file; so an RCS file that is only a few KB wont have any space added; that way this mechanism doesn't slow down/bloat small repositories. The amount of white space might be chosen to align data structures with disk block boundaries. 5) My main concern is to do with concurrency/consistency requirements; is the file rewrite essential to ensure consistency, or is the locking that is carried out sufficient? Does this make sense? Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
[Resend: I sent it with the wrong 'from' address - apologies if you get both] * Mark D. Baushke ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi Mark, Thanks for your reply. Dr. David Alan Gilbert [EMAIL PROTECTED] writes: So - here are my questions/ideas - I'd appreciate comments to tell me whether I'm on the right lines: 1) As I understand it the tag data is the first of the 3 main data structures in the RCS file (tag, comments, diffs) and that when I do pretty much any CVS operation I rewrite the whole file - is this correct? CVS write operations on a foo.c,v repository file will write ,foo.c, and then when the write operation is successful and without any errors, it does a rename (,foo.c,, foo.c,v); to make the new version the official version. While the ,foo.c, file exists, RCS commands will consider the file locked. It is desirable to use RCS write semanitcs as many other tools out there (cf, ViewCVS) use RCS on the repository and want to obey RCS locking. OK, if I create a dummy ,foo.c, before modifying (or create a hardlink with that name to foo.c,v ?) would that be sufficient? Or perhaps create the ,foo,c, as I normally would - but if I can use this overwrite trick on the original then I just delete the ,foo.c, file. Is the problem that things are allowed to read the original foo.c,v while you are creating the new version? be configured). So, yes, whitespace is mostly irelevent between sections. Great. 3) So the idea is that when I add a tag I add a bunch of white space after the tag (lets say 1KB of spaces split into 64 byte lines or similar); when I come to add the next tag I check if there is plenty of white space, if there is then instead of rewriting the file I just overwrite the white space with my new tag data; if there is no space then as I rewrite the file I add another lump of white space. This has the potential to more easily corrupt the RCS file if the operation is interrupted for any reason. The act of rewriting adding extra space would be performed using the existing mechanism (with just some extra add space created in RCS_rewrite); so that can't be a problem. So the issue is what happens if the interrupt occurs as I'm overwriting the white space to add a tag; hmm yes; is it possible to guard against this by using a single call to write(2) for that? Is that the problem you are thinking of? It would be more robust to enhance CVS to use an external database for tagging information instead of putting the tagging information into the RCS files directly than to rewrite parts of the RCS file and hope that the operation didn't corrupt the file along the way. Sure, seperating the tagging data out is much neater; but what I was looking for here was a simple speed up which didn't require anything extra and would be fully compatible with existing tools. You may wish to consider looking at Meta-CVS as I believe that Kaz keeps a lot of the branching information outside of the RCS files already. See http://users.footprints.net/~kaz/mcvs.html for more details on Meta-CVS. If I was changing to another tool then I'd have a much larger set of tools to consider (e.g. subversion) but I'd rather stick with plain CVS if I can - I've got clients on lots of (weird) OSs that work via pserver and an infinite number of scripts built around CVS. Thanks for the reply, Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
* Paul Sander ([EMAIL PROTECTED]) wrote: Hi Paul, Thanks for the reply, Everything that Mark says is true. I'll add that some shops optimize their read operations under certain conditions, and such optimizations would break if the RCS files are updated in-place. What happens is that, if the version of every file can be identified in advance (using version number, tag, or branch/timestamp pair) then they can invoke RCS directly to fetch file versions, read metadata, and so on. This sidesteps CVS' overhead and can increase performance by as So are these tricks *never* performed by cvs itself? i.e. would my trick (if I can solve the interrupted write case) be completely safe with any use of cvs as long as you didn't access the files externally? Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Idea for reducing disk IO on tagging operations
* Mark D. Baushke ([EMAIL PROTECTED]) wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dr. David Alan Gilbert [EMAIL PROTECTED] writes: OK, if I create a dummy ,foo.c, before modifying (or create a hardlink with that name to foo.c,v ?) would that be sufficient? I would say that it is likely necessary, but may not be sufficient. Hmm ok. Or perhaps create the ,foo,c, as I normally would - but if I can use this overwrite trick on the original then I just delete the ,foo.c, file. I am unclear how this lets you perform a speedup. I only create the ,foo.c, file - I don't write anything into it; the existence of the file is enough to act as the RCS lock; if I can do my inplace modification then I delete this file after doing it, if not then I proceed as normal and just write the ,foo.c, file and do the rename as you normally would. Is the problem that things are allowed to read the original foo.c,v while you are creating the new version? I am given to understand that many of the anicillary tools that surround CVS make use of being able to read a consistent ,v file at all times. This is very tricky; I don't think in our case we use any such tools (we might have a cvs/web thing for browsing it, but this is probably not critical); and as long I can guarentee what I do is safe as far as CVS itself is concerned I think I'd be prepared to go for it as a configurable mechanism. So the issue is what happens if the interrupt occurs as I'm overwriting the white space to add a tag; hmm yes; Correct. Depending on the filesystem kind and the level of I/O, your rewrite could impact up to three fileblocks and the directory data. is it possible to guard against this by using a single call to write(2) for that? Not for all possible filesystem types. Is that the problem you are thinking of? Yes. Even worse things can happen in this regard if the filesystem is a 'stateless' one such as an NFS mounted directory (we keep advising folks against using them, but I know for a fact that they are still used). OK, my conscience will let me carefully ignore NFS issues given the pain it causes me elsewhere (and I make my mechanism switchable). What happens if I only used the overwrite mechanism if none of the characters being modified crossed a 512 (e.g.) byte boundary offset in the file? Since the spaces were actually written in a previous operation we can assume that the space is allocated and no allocation operation is going to happen at this point (mumble filesystem journalling mumble!). Sure, seperating the tagging data out is much neater; but what I was looking for here was a simple speed up which didn't require anything extra and would be fully compatible with existing tools. And you are finding that existing tools torture the assumptions you are able to make about the CVS repository. Nod; it is quite painful! FWIW: (In my personal experience) using a SAN solution for your repository storage allows you much better throughput for all write operations in the general case as the SAN can guarentee the writes are okay before the disk actually does it. But when you throw a GB of writes at them in a short time from a tag accross our whole repository they aren't going to be happy - they are going to want to get rid of that backlog of write data ASAP. Optimizing for tagging does not seem very useful to me as we typically do not drop that many tags on our repository. In the company I work for we are very tag heavy, but more importantly it is the tagging that gets in peoples way and places the strain on the write bandwidth of the discs/RAID. Dave -Open up your eyes, open up your mind, open up your code --- / Dr. David Alan Gilbert| Running GNU/Linux on Alpha,68K| Happy \ \ gro.gilbert @ treblig.org | MIPS,x86,ARM,SPARC,PPC HPPA | In Hex / \ _|_ http://www.treblig.org |___/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs release does not update the CVS/Entries(.log) file
Larry Jones writes: Reinstein, Shlomo writes: I would like to use cvs release to get rid of a sub-tree of my project. However, I noticed that cvs release does not update the CVS/Entries (or CVS/Entries.log) file, which causes a problem later when I want to run other commands, like cvs status, cvs tag, etc. Indeed, that's a long-standing bug that's unfortunately difficult to fix. The workaround is to just delete the directory from CVS/Entries by hand. If the sub-dir was deleted using cvs remove sub-dir then issuing the command cvs update -d -P sub-dir will remove the sub-dir entry from the CVS/Entries file. If there exists files in the sub-dir in the repository but you simply don't want the sub-dir in your working dir, then try referring a time when the sub-dir didn't exist. In general 1980 almost nothing existed: cvs update -d -P -D 1980-01-01 sub-dir. (Either way, it doesn't matter if you earlier have removed the sub-dir using cvs release or rm -r, or not.) (The -P will remove the sub-dir in your working dir, if it exists and becomes empty. It will not be removed if it contains changed or unknown files. In that case be ware of sticky date if -D was used.) (Tested in CVS version 1.10 and 1.11. Found out by trial and error so I don't know if there is a better way.) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Renaming a file in the trunk but not in branches
Hi, Will the following commands work to rename a file in the trunk but retain the old file name in all its branches?: cvs co module cvs remove -f oldfile cvs add newfile cvs commit -mRenamed oldfile to newfile oldfile newfile Thanks, -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Renaming a file in the trunk but not in branches
One additional question on this: Is there any way to preserve history on the new file? My understanding is that if I copy the oldfile,v to newfile,v on the server and then run the commands below on the client, then this will affect the trunk as well as the branches. Is this true? If true, is there any other way to rename a file in the trunk retain the history of the oldfile in the newfile while keeping the oldfile intact in the branches? Thanks, -Dave -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Friday, March 11, 2005 10:33 AM To: David Leskovac; info-cvs@gnu.org Subject: RE: Renaming a file in the trunk but not in branches David Leskovac wrote: Will the following commands work to rename a file in the trunk but retain the old file name in all its branches?: cvs co module cvs remove -f oldfile cvs add newfile cvs commit -mRenamed oldfile to newfile oldfile newfile Yes, that will work fine. -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. ( http://www.leitch.com ) Columnist, C/C++ Users Journal ( http://www.cuj.com/experts ) ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server times
On Thursday 24 February 2005 11:33 pm, Guus Leeuw jr. wrote: -Original Message- From: [EMAIL PROTECTED] [mailto:info-cvs- [EMAIL PROTECTED] On Behalf Of David A. Bartmess Sent: vendredi 25 février 2005 06:53 On Thursday 24 February 2005 08:24 am, Jim.Hyslop wrote: rakesh mailgroups wrote: does anyone know if the repository server having a different time than local PCs will cause issues with CVS? None whatsoever. CVS was designed to be able to operate with workstations in multiple time zones (unlike, say, Visual Source Safe). All times are converted to UTC before being stored in the repository. But if a local PC was used to work on files, having a current time at checkin of 11:30 MDT, and the server at time of checkin is 13:35 EDT, this could seriously screw with any automation that relies on the datetime stamp to know if a build has already included that change (i.e., cruisecontrol). Uhm? EDT != UTC MDT != UTC *All* CVS Client - Server and Server - Client communication is (virtually) done in UTC. Meaning, as Jim said, local PC uses MDT, talks to CVS server, and CVS server converts to UTC, and also CVS server uses UTC, talks to CVS client, and CVS client converts to MDT. The EDT settings of your server are totally unimportant within the CVS server! proud We (as in previous job) used to manage a CVS repo in Germany, and access it from within the States. No problems in timing *ever* occurred. /proud I was talking about the 5 minute difference in my example, though. Not in the timezone difference. Rakesh asked about a difference in time. That could have weird consequences, depending on the usage on checkout... -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS Server times
On Thursday 24 February 2005 08:24 am, Jim.Hyslop wrote: rakesh mailgroups wrote: does anyone know if the repository server having a different time than local PCs will cause issues with CVS? None whatsoever. CVS was designed to be able to operate with workstations in multiple time zones (unlike, say, Visual Source Safe). All times are converted to UTC before being stored in the repository. But if a local PC was used to work on files, having a current time at checkin of 11:30 MDT, and the server at time of checkin is 13:35 EDT, this could seriously screw with any automation that relies on the datetime stamp to know if a build has already included that change (i.e., cruisecontrol). Just FYI... -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Restricting use of 'cvs rtag' 'cvs tag' commands [2nd try]
[I sent this msg 10 days ago noone responded. So, I'm trying again.] Hello, We are currently using an ancient version of CVS (1.11.1p1) on a rather old Linux server (Red Hat 6). I intend to upgrade to CVS 1.11.19 eventually upgrade the Linux OS. In the course of our CVS upgrade discussion we started discussing how to increase security with regards to CVS access. I am aware of the cvsacls script that provides fairly fine-grained permissions to do check-ins but is there also a way of restricting who is allowed to do certain cvs commands? In particular, we would like to restrict who can create/delete tags branch tags. Is it possible to restrict 'cvs tag' 'cvs rtag' on a user or group level? Thanks, -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Restricting use of 'cvs rtag' 'cvs tag' commands [2nd try]
Install cvs in a different place than the version you are using. Make a script named cvs in the current location of cvs. That script should check the cvs commands vs. valid users. If everything is OK, then it should invoke the new cvs in the new place with the arguments passed to it. This is an interesting idea. This won't protect you from truly malicious developers who invoke cvs directly from the new location, but you probably have already fired those people from your project. :-) None of the developers are malicious. The problem came up because on 3 separate occasions, a developer who is not very familiar with CVS somehow deleted 3 active branches. As to firing developers, that's out of my realm. I am just a lowly release engineer. :-) One person suggested an open source product called Sinis. http://sinis.sourceforge.net/ This product intrigues me. Has anyone on this list used Sinis? -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: jar files in cvs repository
I'm not sure of the speeds, but it's a two-edged sword. Keeping full copies of everything bloats the database requirements for CVS, making the disk space an issue. And I couldn't say whether not using the diff to create deltas to keep instead would be faster or slower than checking in a full copy every time. But for source code, etc, I'd quickly say that checking in a full copy is a waste, since it's not that big usually, and the time differences would be minimal... Maybe someone else has actually done timing on this? On Monday 21 February 2005 12:39 am, Jesper Vad Kristensen wrote: David Bartmess wrote: Used in the cvswrappers file, the -m gives the mode of the file to the cvs admin command, setting the mode of the file to either COPY (do not delta the file, put a full version in every time) or to MERGE (put only delta of file changes into the repository)... On Friday 18 February 2005 01:28 am, Jesper Vad Kristensen wrote: Larry Jones wrote: It's better to do: *.[Gg][Ii][Ff] -k 'b' -m 'COPY' (Amazing what you can do in CVS!) But why the -m 'COPY'? That's very interesting. We're working with binary source code here and have some performance issues when retrieving stuff from branches (due to the backtracking or whatever it's called). Would you - or anyone else here - happen to know if storing the whole copy of the file each time speeds up retrieval in branches? Regards, Jesper Vad Kristensen ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: braches best usage
What I've done in this scenario in the past is to create an integration branch. NOT a QA branch, but one which the developers only are allowed to merge to, just to check the viability of their changes. A cruisecontrol system runs a continuous build on the integration branch, to do both of 1) test the build to make sure no one breaks it syntactically, and 2) run the junit or other automated tests to ensure they didn't break it logically. This isn't much of an overhead, and if the developer does any testing at all on his box, using his copy of the integration branch, the results are almost always good to go to QA (merged to the QA branch for the next QA build). Note that the developers should merge THEIR branch directly to the QA branch (or the SCM admin should) to avoid introducing non-tested code merged from other developers. It's fairly simple to setup the scripts to allow them to do this without much hassle, and it makes for an even better chance at passing QA's testing if it goes through these steps. I've always been able to (after a proving period) convince the management it's worth a minor hassle on the developer and/or SCM to get this much done... On Monday 21 February 2005 05:50 pm, bobby temper wrote: Hi, I have a point that confuses me about branches usage. We have developpers that want to isolate themselves from the trunk, by creating a branch. After that, the code needs to go to QA. This is where i'm confused: how can we make that code go to QA? If we merge the code from the branch to the trunk, before doing QA, what if that code cannot go to the next release? I was thinking of creating a QA branch, and have everyone wanting their code to be QAed needs to merge their code to that branch. But then again, this might create a little overwork.. What's the best thing to do? I'm a bit lost... Best regards, Bobby _ Express yourself instantly with MSN Messenger! Download today - it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/ ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: jar files in cvs repository
Used in the cvswrappers file, the -m gives the mode of the file to the cvs admin command, setting the mode of the file to either COPY (do not delta the file, put a full version in every time) or to MERGE (put only delta of file changes into the repository)... On Friday 18 February 2005 01:28 am, Jesper Vad Kristensen wrote: Larry Jones wrote: It's better to do: *.[Gg][Ii][Ff] -k 'b' -m 'COPY' (Amazing what you can do in CVS!) But why the -m 'COPY'? My man cvs says: -m message Use message as log information, instead of invoking an editor. Regards, Jesper Vad Kristensen Aarhus, Denmark. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: cvs and ssh
* Serbulent UNSAL [EMAIL PROTECTED]: # cvs -d /var/cvsroot init # chown -R cvs.cvs /var/cvsroot #export CVS_RSH=ssh Here is the error message usta:/home/usta# cvs -d :ext:[EMAIL PROTECTED]:/var/cvsroot checkout module Password: Did you import anything in your repository before doing a checkout? ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Undo check out
As Paul said, you don't have to undo the checkout. If you checked out a wrong module, remove that directory, and try again. The repository won't have anything locked unless (again, as Paul said) you used the cvs admin command to lock the files... On Wednesday 16 February 2005 12:35 am, Paul Sander wrote: You don't. CVS doesn't have the notion of a traditional checkout that involves locking. There may be a record in history that a workspace has been created (which is what CVS calls a checkout) that can be countered by invoking the cvs release command. If, on the other hand, someone is trying to simulate a reserved checkout mechanism using the cvs admin command, there's a different option to that command that clears the RCS level lock. But using cvs admin in this manner is strongly discouraged. On Feb 15, 2005, at 10:16 PM, [EMAIL PROTECTED] wrote: I have wrongly checked out a compononet. How will I undo this checkout. Removing lock manually is one option but is there any other better way to do this. -- Paul Sander | When a true genius appears in the world, you may [EMAIL PROTECTED] | know him by this sign: that all the dunces are in | confederacy against him. -- Jonathan Swift, writer. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs -- David A. Bartmess Software Configuration Manager / Sr. Software Developer eDingo Enterprises http://edingo.net _ jSyncManager Development Team (http://www.jsyncmanager.org) jSyncManager Email List (https://lists.sourceforge.net/lists/listinfo/jsyncmanager-devel) But one should not forget that money can buy a bed but not sleep, finery but not beauty, a house but not a home, medicine but not health, luxuries but not culture, sex but not love, and amusements but not happiness. ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Info-cvs Digest, Vol 27, Issue 40
When you added the files, did you specify -kb for the add command for the binary jar files? If not, you'll have to change the status of the files using the cvs admin command as follows: cvs admin -kb myJarFile.jar cvs update -A myJarFile.jar here, you need to copy the original jar file back over the sandbox version, as the sandbox version is corrupted cvs commit This will reset the status of the jar file(s) to a binary format, meaning no translation will be done on the file. Then you copy the good version back over the sandbox (corrupted) version, and commit it. If you imported (created a NEW module under CVS by importing the entire directory structure), it should have noted the binary status automatically because of the magic numbers, but sometimes it can make mistakes. For future reference and possible use now, you can checkout and modify the CVSROOT/cvswrappers file from the repository, and add the filename pattern in the syntax: pattern option 'value' [option 'value' ...] for example, add the following line to make all *.jar files binary when added. *.jar -m 'COPY' -k 'b' This tells CVS when a jar file is added, use the COPY merge strategy (it keeps a complete copy of the file, instead of just the delta version), and to mark it as binary mode in the CVS status for the file. if you modify the cvswrappers file BEFORE you import, you should be able to avoid this hassle... Hope this helps! On Wednesday 16 February 2005 10:01 pm, Rajeev R wrote: Hi all, I am using eclipse cvs repository view for downloading the cvs repository jar files. Could any one pls tell me how the jar files can be downloaded after importing them to the cvs repository. Thanks Regards, Rajeev.R On Wed, 16 Feb 2005 08:56:45 -0800 (PST), [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Send Info-cvs mailing list submissions to info-cvs@gnu.org To subscribe or unsubscribe via the World Wide Web, visit http://lists.gnu.org/mailman/listinfo/info-cvs or, via email, send a message with subject or body 'help' to [EMAIL PROTECTED] You can reach the person managing the list at [EMAIL PROTECTED] When replying, please edit your Subject line so it is more specific than Re: Contents of Info-cvs digest... Today's Topics: 1. jar files in cvs repository (Rajeev R) 2. RE: jar files in cvs repository (Jesper Vad Kristensen) 3. Re: Undo check out (David A. Bartmess) -- Message: 1 Date: Wed, 16 Feb 2005 17:47:30 +0530 From: Rajeev R [EMAIL PROTECTED] Subject: jar files in cvs repository To: info-cvs@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=US-ASCII Hi , We have a cvs repository that contains jar files. When I imported the jar files, I could not get the jar files as such. All the jar files had no content ,when I checked them out from the cvs repository and of 1 KB size . Pictures and .java files are coming perfectly ,but jar files are not downloading perfectly. Could any one please help me in this case, where i want to download jar files from the cvs repository perfectly, when checked out. Thanks Regards, Rajeev, Software Engineer -- Message: 2 Date: Wed, 16 Feb 2005 14:30:42 +0100 From: Jesper Vad Kristensen [EMAIL PROTECTED] Subject: RE: jar files in cvs repository To: info-cvs@gnu.org Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=us-ascii Raajev, We have a cvs repository that contains jar files. When I imported the jar files, I could not get the jar files as such. All the jar files had no content ,when I checked them out from the cvs repository and of 1 KB size . Pictures and .java files are coming perfectly ,but jar files are not downloading perfectly. It's a bit unclear what you're doing, and what you did up to the point where you wish to checkout the files again, but are you sure you didn't by accident corrupt the JAR files (they're BINARY, right, so you gotta -kb them)? Regards, Jesper Vad Kristensen Aarhus, Denmark -- Message: 3 Date: Wed, 16 Feb 2005 06:56:26 -0700 From: David A. Bartmess [EMAIL PROTECTED] Subject: Re: Undo check out To: info-cvs@gnu.org Cc: [EMAIL PROTECTED] Message-ID: [EMAIL PROTECTED] Content-Type: text/plain; charset=iso-8859-1 As Paul said, you don't have to undo the checkout. If you checked out a wrong module, remove that directory, and try again. The repository won't have anything locked unless (again, as Paul said) you used the cvs admin command to lock the files... On Wednesday 16 February 2005 12:35 am, Paul Sander wrote: You don't. CVS doesn't have the notion of a traditional checkout that involves locking. There may be a record in history that a workspace has
Restricting use of 'cvs rtag' 'cvs tag' commands
Hello, We are currently using an ancient version of CVS (1.11.1p1) on a rather old Linux server (Red Hat 6). I intend to upgrade to CVS 1.11.19 eventually upgrade the Linux OS. In the course of our CVS upgrade discussion we started discussing how to increase security with regards to CVS access. I am aware of the cvsacls script that provides fairly fine-grained permissions to do check-ins but is there also a way of restricting who is allowed to do certain cvs commands? In particular, we would like to restrict who can create/delete tags branch tags. Is it possible to restrict 'cvs tag' 'cvs rtag' on a user or group level? Thanks, -Dave ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Can I allow user to only have permission in branches but not HEAD?
Hi, I have a question about how access permissions on branches and HEAD. I want to restrict certain CVS users to only be able to commit their changes to branches but not the HEAD. Yet at the same time, I want to allow them to check out modules from the HEAD. Is this doable? Thanks! David Jiao ___ Info-cvs mailing list Info-cvs@gnu.org http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Please help troubleshooting connection problem via SSH
Chris Weiss [EMAIL PROTECTED] writes: I've got one client who is having trouble connecting to our CVS server. I'm trying to troubleshoot the problem, but am not having much luck. Our setup is CVS server 1.11.5, client 1.11.1.3, we're connecting via SSH tunnel. We've got the keys syncronized, so the client doesn't need to enter a password to connect. I'm able to successfully connect using the client's account, but he is not. We've been successfully using this system for a while with a dozen users who are having no issues connecting. He can SSH in, so we know it's not a blocked port issue. The client's machine is WinXP (unknown if SP2 is installed) Client-wise, we're using WinCVS and Turtle - I've tried CVS from the command prompt as well with no success. The symptoms are - if trying to do a Checkout or get a module list, the client freezes with no output at all. We've left it for minutes at a time with no response. Here is the client's output for CVS Version: Client: Concurrent Versions System (CVSNT) 1.11.1.3 (Build 57k) (client/server) Server: Does anyone have any ideas what could be causing his issues or any further steps to take to troubleshoot this? I'm new to the whole CVS thing (my experience was all Perforce) and this is all a trial-by-fire for me. You say that you can use the client's account no problem, but you don't mean his machine, just his login info,of course. It sounds as if his CVSROOT string is incorrect. What did you all put into the preferences section of WinCVS to connect him to your system? That wouldn't stop him from manually SSHing into the system, but it would certainly keep WinCVS from connecting. Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Please help troubleshooting connection problem via SSH
Chris Weiss [EMAIL PROTECTED] writes: J. David Boyd wrote: Chris Weiss [EMAIL PROTECTED] writes: I've got one client who is having trouble connecting to our CVS server. I'm trying to troubleshoot the problem, but am not having much luck. Our setup is CVS server 1.11.5, client 1.11.1.3, we're connecting via SSH tunnel. We've got the keys syncronized, so the client doesn't need to enter a password to connect. I'm able to successfully connect using the client's account, but he is not. We've been successfully using this system for a while with a dozen users who are having no issues connecting. He can SSH in, so we know it's not a blocked port issue. The client's machine is WinXP (unknown if SP2 is installed) Client-wise, we're using WinCVS and Turtle - I've tried CVS from the command prompt as well with no success. The symptoms are - if trying to do a Checkout or get a module list, the client freezes with no output at all. We've left it for minutes at a time with no response. Here is the client's output for CVS Version: Client: Concurrent Versions System (CVSNT) 1.11.1.3 (Build 57k) (client/server) Server: Does anyone have any ideas what could be causing his issues or any further steps to take to troubleshoot this? I'm new to the whole CVS thing (my experience was all Perforce) and this is all a trial-by-fire for me. You say that you can use the client's account no problem, but you don't mean his machine, just his login info,of course. It sounds as if his CVSROOT string is incorrect. What did you all put into the preferences section of WinCVS to connect him to your system? That wouldn't stop him from manually SSHing into the system, but it would certainly keep WinCVS from connecting. Dave I'm pretty sure it's not a CVSROOT issue unless there's something machine specific in that variable. We'd set it multiple times over the course of testing (it's not persistent in the shell) and several of those times were copy/pastes from CVSROOT settings that worked successfully on my machine (we've been debugging via IM). I'm also guessing that if there was a bad CVSROOT, at least one of the clients would have given a descriptive error and not just hung. Thanks for the ideas though! So you are saying that the client can connect to CVS through SSH on the command line? Just not in WinCVS or Turtle? That definitely would not be a CVSROOT problem then. Sorry for being no help... ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Cannot access ^M/CVSROOT
I am having trouble access a CVS repository that I have been able to access in the past. I'm using CVS from the cygwin distribution on Windows XP SP2. I'm using cvs version 1.11.17. When I try a command, I get the error: Cannot access /src/master^M/CVSROOT No such file or directory What is interesting is that between the master and the /CVSROOT is a 0x0d character. This seems to be causing trouble, Any idea where this is coming from? Any idea what to try? Any help would be appreciated. David Robison -- David R Robison Open Roads Consulting, Inc. 708 S. Battlefield Blvd., Chesapeake, VA 23322 phone: (757) 546-3401 e-mail: [EMAIL PROTECTED] web: http://openroadsconsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: [cvsnt] Re: Problem with OpenSSH version 3.9p1
I rolled back to an older version of cygwin1.dll and all works fine now! David Tony Hoyle wrote: David Robison wrote: I recently did an update from cygwin and updated to OpenSSH version 3.9p1. Now, every time I try to work with a CVS repository that uses SSH authentication, the csv process hangs with no output. CVS works fine for repositories with pserver authentication. Any ideas what might be going on? Any way I can further debug this? I'm using CVSNT version 2.0.41a that came with WinCVS. It sounds like that openssh is broke, if the older one worked. Have you tried asking on the cygwin list if anyone else if having the problem? Tony ___ cvsnt mailing list [EMAIL PROTECTED] http://www.cvsnt.org/cgi-bin/mailman/listinfo/cvsnt -- David R Robison Open Roads Consulting, Inc. 708 S. Battlefield Blvd., Chesapeake, VA 23322 phone: (757) 546-3401 e-mail: [EMAIL PROTECTED] web: http://openroadsconsulting.com ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Do most people checkout read-only and use cvs edit?
I have a question about how people use CVS. How common is it to always checkout and update read-only, and then use cvs edit when you start working on a file? Or, do people checkout read-write and never use cvs edit? I have always thought that modules should be checked out read-only, and cvs edit is only used when you start to work on a file. However, I'm getting the impression that that appears to be an alternative strategy, and even deemphasized. In fact, in the WinCVS interface, the cvs edit functionality is under the Trace submenu, hiding it from the first-level menu. Other SCMs use the strategy that I'm used to as the primary strategy (checkout read-only, and do a specific operation to put the file into edit mode). ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: Do most people checkout read-only and use cvs edit?
I'm not talking about locking. It's always impractical to check out with locks, in any SCM. I'm just talking about what happens in the user's client view. I was under the impression before that cvs edit just affects the file in the user's client view. Does this also lock the file on the server? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tom Copeland Sent: Wednesday, July 07, 2004 11:12 AM To: [EMAIL PROTECTED] Subject: Re: Do most people checkout read-only and use cvs edit? On Wed, 2004-07-07 at 14:01, Karr, David wrote: Or, do people checkout read-write and never use cvs edit? Yup, that's what I do. Optimistic locking and all that sort of thing, you know... Yours, Tom ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
inflate: unknown compression method after server upgrade to 1.11.16
When I use a client which inserts the global '-l' option together with my newly upgraded server, I get the expected global `-l' option ignored warning. However, if I also specify a compression level, I get the following: [EMAIL PROTECTED] tools] cvs -nq -z1 up cvs update: inflate: unknown compression method cvs [update aborted]: reading from server: Input/output error Server: cvs 1.11.16 RedHat 7.2 Client: cvs 1.11.1p1 RedHat 7.2 Note that I have many clients deployed, so I'd like to understand the problem (not just deploy newer clients). Thanks, David Please respond to this newsgroup, not my e-mail address. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
RE: File date and timestamp
Thanks for the info. The reason the timestamp is important is because the file is part of an external delivery. the customer has previous deliveries and flags files whose timestamps have changed. As a result, they wonder why the timestamp changed on this binary file, yet we didn't inform them of any changes with that particular capability. -Original Message- From: Jim.Hyslop [mailto:[EMAIL PROTECTED] Sent: Monday, June 28, 2004 11:45 AM To: Flagg, David; [EMAIL PROTECTED] Subject: RE: File date and timestamp Flagg, David wrote: This is a re-post. This seems like it could possibly be a common problem someone might have. Is there a more appropriate forum somewhere else? Thanks. Hmmm.. I thought I saw a response to your original message from someone else already, but I don't see it in my 'trash' or in the archive. -Original Message- I have a binary file that is in my repository, libtemp.a, which has the following timestamp in cvsroot (i.e., timestamp in the Unix filesystem): Jun 18 09:42. Apparently, this is the time when I last tagged the file. That would make sense; applying a tag modifies the RCS file. When I check out the file (with WinCVS, by the way), the date on the file is (as viewed by Win 2K): 5/3/2004 6:47 PM. This is the date/time when I last committed the file. This also agrees with the timestamp in the Entries file. When I committed the file, the timestamp on the file was 12/24/2003 2:23 PM. It is important that this be the timestamp that is associated with the binary file, as it is pulled in from another source. When I check this file out, I want the timestamp to continue to be 12/24/2003 2:23 PM. Timestamps are an interesting issue. The problem is, how do you decide which timestamp to use on the checked-out file? Even if you succeed, there is the issue of updating to a specific tag. If you issue the command 'cvs update -r1.1' the timestamp of the file will become the current date and time. While this may seem strange and unintuitive at first, you must consider that CVS also interacts with other systems - such as build systems. If CVS used the original modification timestamp or the check-in timestamp, the dependency system would not flag the dependencies as out-of-date. (1) Is there a way that I should have committed this file such that I can get the behavior I want? I believe that the rcs command allows options to specify the timestamp to apply to the file. Or, you can hack the CVS source to get the behaviour you want. This introduces another issue, though - 'cvs log' and anything else that uses the date option works on the date in the RCS file. You could introduce subtle, unexpected behaviour changes with this modification. (2) How can I correct the situation for this particular file? You could manually edit the RCS file. It sounds to me, though, like you need a configuration management system that is aware of things beyond the current scope. Why is it so important to maintain the exact timestamp of the binary file? -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
File data and timestamp
I have a binary file that is in my repository, libtemp.a, which has the following timestamp in cvsroot (i.e., timestamp in the Unix filesystem): Jun 18 09:42. Apparently, this is the time when I last tagged the file. When I check out the file (with WinCVS, by the way), the date on the file is (as viewed by Win 2K): 5/3/2004 6:47 PM. This is the date/time when I last committed the file. This also agrees with the timestamp in the Entries file. When I committed the file, the timestamp on the file was 12/24/2003 2:23 PM. It is important that this be the timestamp that is associated with the binary file, as it is pulled in from another source. When I check this file out, I want the timestamp to continue to be 12/24/2003 2:23 PM. (1) Is there a way that I should have committed this file such that I can get the behavior I want? (2) How can I correct the situation for this particular file? Thanks! ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: how to checkin binary files
May someone tell me how to checkin a binary file into my repository? Thanks a lot.. man 1 cvs Look for the -k options. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Major revision numbers
[EMAIL PROTECTED] wrote: revision numbers are for CVS's internal use, you should not care what they are. Use tags if you want meaningful information. Weee... for the most part I agree. However, there are times when you need to compare two revisions that are not tagged. If we followed the philosophy that you never use or see the numeric revision, then you'd have to apply two tags for the sole purpose of seeing what changed between the two revisions. It's much easier to say cvs di -r1.123 -r1.124 Right. In that case, you're using 1.123 and 1.124 as arbitrary designators (magic cookies), and you still shouldn't care what they are, as long as you can type them fairly easily. I don't think Larry is saying that you shouldn't refer to them, but that it shouldn't matter exactly what they are. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Binary release announcements?
[ On Wednesday, February 18, 2004 at 10:21:41 (-0500), Jim.Hyslop wrote: ] Subject: RE: Binary release announcements? If you can't, or won't, build the software you use yourself then you need to find someone who can _and_ who you trust to do that for you. Some people seem to be awfully trusting. Perhaps that's some big software company like Microsoft. Perhaps it's just some group of volunteers who stake their reptuations on the quality of the software they create (even though most every one will disclaim all responsibility for damages or loss you might incur when using their software :-). Why put that parenthetical observation only after your second alternative? I haven't seen any software company act as if it took responsibility for such damages or loss. Software license agreements and EULAs haven't changed from the days when they were guarantees that these things were disks, and would remain so for ninety days, coupled with a long list of things you couldn't do with any software you happened to find on there. The problem with computers and digital networking is that the malicious acts can be perpetrated several steps removed from where one might expect them to happen and by the time anyone's aware of what's happened it's far too late because these speedy little machines and wire's we've created have already spread the damage further and wider than any human could ever imagine possible without understanding the many quantum leaps computing technology gives the criminal. PLEASE read Schneier's book Secrets Lies. Greg and I have disagreed before. This isn't one of those times. I don't know if there are other good books that cover the same ground, but I do recommend that one. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Pros/Cons - Concurrent Editing
What are the pros and cons of concurrent editing?. CVS supports and advocates concurrent editing, whereas configuration tools like VSS use the locked model of editing, to which the developers are very much used to. What are the benefits of concurrent editing ( using CVS ) and what problems could arise? In my experience, concurrent editing happens. When Jane is working on the next major feature, Edward is going to get this request for a quick bug fix, if nothing else. Or Bill and Nancy are working on different features, but they both require making minor changes to three programs in common. What tools like VSS do in this case is force you to work around them. Jane releases the file, Edward changes it, then Jane grabs it again and has to incorporate Edward's fix. (I've seen people in Jane's position forget to incorporate those fixes, also. It's real easy to copy the changed file over and forget to merge in the fix.) CVS encourages this sort of thing, and supports it. In CVS, Jane picks up Edward's change automatically, and the tool supports the merging of fixes. While there are some software practices that are best avoided, and which you do not want your tools to encourage, concurrent editing cannot be avoided in general, and it is best if your tools support it. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Best Practices enquiry
On the flip side, and maybe this is what Jim really meant, you can tag your committed versions on the contributor branch when the bug fix is done (and after the merge is complete). Then remember that tag for the next bug fix. You can use that tag as the common ancestor for the next merge. The bad part of this is that you must religiously tag the contributor branch after every merge (which is counter-intuitive), and you must remember the tag (perhaps for a long period of time) until the next bug fix. Note also that this procedure must be bootstrapped by applying the first bug fix tag at the time the branch is created. All told, this is a fine method that also fits neatly into the best practice category. If you can get your developers to use a script to merge (which they'll likely want to do when they see the manual way), and have a consistent tag naming convention, you can automate the merging process. I did that once, and it worked very well. The developers were happy, and I was happy not to have to deal with user merge problems. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS server upgrade?
Jim, Just wondering what minor problems you had, just in case they might pertain to other peoples' migration strategies (or my own someday)? Thanks! David R. Chase Senior Unemployed Software Developer ; ) - Original Message - From: Jim.Hyslop [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] Sent: Monday, February 02, 2004 3:00 PM Subject: RE: CVS server upgrade? Courier [mailto:[EMAIL PROTECTED] wrote: Here is I would like to do: I will take currently cvs server off line, then tar the whole Repository, then bring up a new system and cp and untar Repository on new server. Our cvs server is a stand alone server. All my users are accessing via pserver. I don't have any problems with username and their password migrations, but just concerned about cvs Repository. When we upgraded our server, we took a similar approach. We scheduled a dry-run of the process ahead of time, just to make sure there were no problems and to work out any unforeseen problems. The dry run proved very valuable, because there _were_ some minor things we had overlooked. This saved us the time (and embarassment) of cutting off our users from the repository multiple times. In order to minimize the impact on the users, we took the original server off-line just long enough to create the tarball. As soon as the tar was complete, we restarted the server in read-only mode (create an empty CVSROOT/writers file to make the whole repository read-only). Thus, people could still check out and browse the repository, but they couldn't check anything in (and thus throw the two repositories out of sync). After we were satisfied the new server was up and running properly, we simply did a DNS switch on the server name (the name the users see is an alias to the actual machine name). -- Jim Hyslop Senior Software Designer Leitch Technology International Inc. (http://www.leitch.com/) Columnist, C/C++ Users Journal (http://www.cuj.com/experts) ___ 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: what's to stop a developer from nuking the repository?
[ On Tuesday, January 20, 2004 at 15:13:08 (-0600), [EMAIL PROTECTED] wrote: ] Subject: Re: what's to stop a developer from nuking the repository? If you have a trusted network and you do feel comfortable with telnet and rlogin then USE THEM -- DO NOT USE PSERVER. The logic for using pserver over ssh would be that it's harder to set ssh up right. Using pserver over SSH is about the biggest fallacy for security I can imagine for anything in this context. However, setting up pserver is easier than setting up ssh. Setting up ssh requires reading more instructions, which are not necessarily as accessible. I set up remote users on a VPN with pserver once because I wasn't familiar with the ssh-agent concept and didn't know what to do. (I know better now.) My point is that setting up cvs with rsh is as easy as using pserver, and that provides more accountability. If you're going to use SSH, then JUST USE SSH for goodness sake! ssh is the correct way to use CVS over anything other than a secure LAN (and I share an earlier contributor's feelings about crunchy on the outside, soft and chewy on the inside LANs). On a secure LAN, rsh is about as easy to set up as pserver and works well. So, it looks to me like we're in fairly argumentative agreement here. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: what's to stop a developer from nuking the repository?
[ On Tuesday, January 20, 2004 at 11:03:38 (-0500), Larry Jones wrote: ] Subject: Re: what's to stop a developer from nuking the repository? I think that's still overstating the case. If you run CVS on a network where you can trust people enough that you're confortable running telnet or rlogin, then pserver is fine. Telnet and rlogin and similar still provide on heck of a lot more accountability (over a trusted network) than pserver could ever possibly do. The key here is accountability, I think. pserver has effectively no accountability, and telnet/rlogin have some (as far as I know). If you have a trusted network and you do feel comfortable with telnet and rlogin then USE THEM -- DO NOT USE PSERVER. The logic for using pserver over ssh would be that it's harder to set ssh up right. Not a really compelling reason, but it's all I can think of. However, setting rsh up is as trivial as setting pserver up, so I'd have to agree here. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
suscribe
___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
verifymsg working with netbeans eclipse?
Title: verifymsg working with netbeans eclipse? Hi, We have the standard verifymsg change from the documentation to check for BugId: some_number but netbeans and eclipse users are getting an error cannot exec /path/bugid.verify - file not found. Path is correct and file permissions are correct in fact via the command line and tortoisecvs it works fine. Anyone have experience with this problem? Thanks, -Dave David E. Muller Configuration Manager Overture Services, Inc. www.overture.com Office: 760.476.6406 Mobile: 760.458.2714 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs-1.11.10 win32 VC98 cannot find assert during build
The following command builds cvs-1.11.9, but not cvs-1.11.10 under
windows:
nmake /f cvsnt.mak CFG=cvsnt - Win32 Debug
The failure appears to be:
link.exe @c:\temp\nma01012.
filesubr.obj : error LNK2001: unresolved external symbol _assert
.\WinDebug/cvs.exe : fatal error LNK1120: 1 unresolved externals
NMAKE : fatal error U1077: 'link.exe' : return code '0x460'
Stop.
There is related information about assert earlier in the build
log:
cl.exe /nologo /MLd /W3 /Gm /GX /Zi /Ob1 /I windows-NT /I
lib /I src /I zlib /D _DEBUG /D WIN32 /D _CONSOLE /D
HAVE_CONFIG_H /Fp.\WinDebug/cvsnt.pch /YX /Fo.\WinDebug/
/Fd.\WinDebug/ /c .\windows-NT\filesubr.c
filesubr.c
.\windows-NT\filesubr.c(766) : warning C4013: 'assert' undefined;
assuming extern returning int
My compiler is Microsoft Visual Studio / VC98.
I don't know much about building on windows, not sure what else
to provide, so here is the seemingly related source code change:
windows-NT$ cvs diff -rcvs_1_11_9 -rcvs_1_11_10 filesubr.c
Index: filesubr.c
===
RCS file: /users/home/tibco/tibadmin/cvs/cvs/windows-NT/filesubr.c,v
retrieving revision 1.1.1.1
retrieving revision 1.1.1.2
diff -r1.1.1.1 -r1.1.1.2
743a744,782
/* char *
* xresolvepath ( const char *path )
*
* Like xreadlink(), but resolve all links in a path.
*
* INPUTS
* path The original path.
*
* RETURNS
* The path with any symbolic links expanded.
*
* ERRORS
* This function exits with a fatal error if it fails to read the link for
* any reason.
*/
char *
xresolvepath ( path )
const char *path;
{
char *hardpath;
char *owd;
assert ( isdir ( path ) );
/* FIXME - If HAVE_READLINK is defined, we should probably walk the path
* bit by bit calling xreadlink().
*/
owd = xgetwd();
if ( CVS_CHDIR ( path ) 0)
error ( 1, errno, cannot chdir to %s, path );
if ( ( hardpath = xgetwd() ) == NULL )
error (1, errno, cannot readlink %s, hardpath);
if ( CVS_CHDIR ( owd ) 0)
error ( 1, errno, cannot chdir to %s, owd );
free (owd);
return hardpath;
}
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS Version CHange
Greg Woods: In CVS the release number of RCS-Id is like any useless and almost atrophied organ -- however it's impossible to give it up without also giving up backwards compatability of the internal repository structure. It also is necessary as a magic cookie - an otherwise meaningless but ordered reference to each revision of a file. When referring to releases, one should always use symbolic tags, but when testing it is often necessary to know which particular revision one is using. I've often found it useful to correlate the results of cvs annotate and cvs diff with the results of cvs log. Sometimes there will be code in a program that isn't working just right, and I don't know what it was supposed to be doing, so tracking it down to the revision that introduced it and getting the PR number out of the checkin comment is very useful. So, we can't get rid of the ability to see the revision numbers, although I wouldn't complain if we got rid of the ability to specify them. Perhaps CVS should just hide the 1. from view, though doing that in the RCS keyword expansion would be fraught with problems too and it may still be needed in many command-line parameters. Perhaps translating it into a symbolic value such as TRUNK. wherever visible would be better. Could be. The RCS revision number looks too much like a standard sort of release designation, and that leads to trouble. It appears to contain more information than is needed to specify a revision. I like the idea of giving the revisions simple numbers (as Subversion does) to show their arbitrariness. I agree that tags should be the _preferred_ way to do this, but I really do not see why you are so vehemently opposed to manually forcing revision numbers under special circumstances. What problems will this introduce? While I'm not as vehement as Greg, I don't see any reason to manually force revision numbers. I see no point in it. At best you can have a crude, awkward, and easy-to-get-wrong substitute to what you can do easily and reliably with tags. Again, under special circumstances, not under day-to-day use. The problem is that once it's been done then it becomes an every-day issue from then to the end of the life of the repository (unless it's undone, of course). It can be very hard to undo. I don't think that having such revision numbers is that much of a problem, but if they are to mean anything whatsoever it is an everyday issue, and it's simply not worth it. The major drawback with tags is that they can be moved or deleted, without any history of the changes. If these sorts of things worry you then perhaps CVS is not the right tool for your needs. :-) Sometimes there is no right tool, but we've argued about that before. CVS is not very much of a policy enforcement tool, if any of one at all. (despite the abilities of features such as taginfo scripting hooks) On the other hand, it is nice to have ways to avoid making irretrievable mistakes (and removing or moving a tag can be that). I've made many of those in my lifetime despite knowing better. As the CVS admin, I managed to remove a branch tag from a directory once, and then modified one of my principles (Never hit the return/enter key before you carefully examined what you've just typed) for doing such by adding the clause and it doesn't count as careful examination if anybody is talking to you at the time. Fortunately, later versions of CVS have made the particular error I made impossible, but taginfo is still a reasonable thing to consider. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Limitation on --allow-root pserver options?
You could consider using xinetd alongside Solaris inetd (just for the CVS
port). It would be a simple experiment to set it up and see if it, too,
exhibits the problem.
[EMAIL PROTECTED] wrote on 12/02/2003
03:38:25 AM:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Mark [EMAIL PROTECTED] writes:
We have cvs pserver 1.11.1p1 setup on solaris 2.8 and a wrapper script
in /etc/inetd.conf to allow many --allow-roots (we have many
apps/groups/business units we provide CM support for, thus the need to
many repos). We use WinCVS 1.3 for the client.
Okay. However, there are many bug fixes to cvs available in the latest
cvs 1.11.9 version of cvs.
Currently we have 58 --allow-root options setup in the wrapper script.
The 58th --allow-root does not work/is not recognized.
When we try to login via pserver:
- the client gets no such repository message
- the server logs a login refused for in /var/adm/messages
When I moved that 58th -allow-root to the top of the -allow-root list,
it worked, but then the new last one in the list, now has the above
described issues.
Well, clearly some problem is being uncovered. If you are able to
upgrade to a newer version of cvs and still have the problem, then
it may be possible to help you debug the problem on this list.
Is this a solaris limitation or a cvs limitation (there are about 2513
characters that make up the --allow-root argument string, excluding
any
spaces)?
I am not aware of such a limitation, however, you could test it
yourself.
Take a simple program like this:
% cat testit.c
#include stdio.h
int main(int argc, char *argv[]) {
int i; for ( i = 0; i argc; i++ ) printf(%d: %s\n, i, argv[i]);
return(0);
}
%
Compile it and give it all of the arguments you setup in your wrapper
script for cvs and see what happens.
I could use different ports on the server to balance out the
repositories but WinCVS 1.3 doesn't retain port info inside the
CVS admin subdirectory files in the workares which causes problems
for users who have to work out of repos on different ports at the same
time. (ie. instead of WinCVS 1.3 gathering all it needs from a
workarea's CVS subdir to commit/update etc... it uses the current port
settings in the WinCVS preferences regardless of what the workarea is
currently being used this is quite annoying and confusing)... if
this issues has been fixed in WinCVS 1.3, please let me know.
Any help/insight/suggestions is appreciated. yes we only have one
solaris server to use, and yes we must have independent
repositories..
Thanks,
Mark
Good luck,
-- Mark
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.3 (FreeBSD)
iD8DBQE/zE+B3x41pRYZE/gRAsJMAJsGOsCUaYAUE++6sIWazSnGfHTV9ACdFVck
Lyqb6jf6h+thjyzNIlIJkUY=
=3nB/
-END PGP SIGNATURE-
___
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: Please help..
Two things. First, did you work for 18 months on something without making backups? If you never made backups, then whether it was a mistake setting up CVS, some other kind of mistake, hardware failure, fire, or theft, you were destined to lose your work. I hope, however you resolve this issue, that you will always make nightly backups in the future. If you are ahead of me, and you have backups after all, then you can always use them to undo whatever you've done. I'm guessing, but at this point it may be easiest. Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. [EMAIL PROTECTED] wrote on 11/26/2003 11:32:10 AM: Hi All, I am seriously new to CVS. I have a large project that has been developed by my self for the past 18 months but is about to be taken on by a few other people so I though CVS would be a good way of working. I seem to have turned all of my original source files within the directory to have a .v extention and a lot of stuff has been added to these files. Please tell me their is an easy way to get my files back! I seem to have figurered out now how to make a repository from my original source files but they all have a double .v (.v.v) file extention now!!! Doh. Thanks in advance!! Cheers John ___ 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: Please help..
You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT stuff etc. My source files are in /home/johnwards/www/sportnetwork I thought I should have done this: CVSROOT=/home/johnwards/www export CVSROOT cvs init Then: cvs import -m SportNetwork first import -d sportnetwork sportnetwork start This was wrong :-( I think. As its changed all my files... I am really confused by the manual...all I want to do is set up CVS using my source files...how on earth do you do it as I am really confused.. John ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Case insensitivity ad nauseum
Is the problem that you're not sure how to get the network drive into the sshd filesystem root? Or that when you try to that it fails? If it were the latter, it would be reminiscent of a similar problem I had trying to get apache to serve files from a network drive on Windows XP. We found that the Local System Account that the apache service ran under by default did not have permissions to access the drive. If you were having trouble with it, you might look into what user the sshd process is running as, and whether that user has permission to access the drive. [EMAIL PROTECTED] wrote on 11/26/2003 02:25:14 PM: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 I settled on a compromise for the nonce. I fixed the latest case insensitivity bug I knew of in 1.11.x and removed case insensitivity support from feature entirely. I've also added some tests of behavior involving heterogeneous combinations of case sensitive and case insensitive clients and servers to both branches though I've yet to get it set up for nightly testing (if anyone knows how to get Cygwin sshd to allow access to a mounted Samba share via its login shell, I could use some assistance). Since things look stable without case insensitivity support, I will probably remove support from stable too if any new bugs crop up. I'll probably roll a new release early next week. Derek - -- *8^) Email: [EMAIL PROTECTED] Get CVS support at http://ximbiot.com! -BEGIN PGP SIGNATURE- Version: GnuPG v1.0.7 (GNU/Linux) Comment: Using GnuPG with Netscape - http://enigmail.mozdev.org iD8DBQE/xP4ZLD1OTBfyMaQRAjN4AJ0dlk5zjIsae5xN6elNbLw9TKpl9ACg2KGD DIdO/rpFI8YlFAqUrOukha4= =q+r2 -END PGP SIGNATURE- ___ 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: Please help..
I had the same thought, Steve, and I think the same concern - given what he did, the repository _might_ have been a valid one the first time through - and it might be a valid repository of the repository now. But without knowing the nuts and bolts of the repository and import process, I can think of reasons why it wouldn't be. Of course, there's not much to lose in performing the experiment, as long as you take care and keep copies of everything. I'll be curious to hear if following these instructions would work. [EMAIL PROTECTED] wrote on 11/26/2003 02:46:10 PM: David, Perhaps John could try this? A suggestion to untangle: 1. Create a repository properly. 2. Copy the .v.v files into the repository manually. 3. Checkout the files into a working directory. (getting a .v file) 4. Copy the .v files manually into the repository. 5. Checkout the files into a working directory. (hopefully getting back the originals.) This assumes that the creating the repository over the original files didn't muck them up too much. John, Don't just try the above suggestion till we get more input. I'm just floating an idea and I think the experts here might have something more to say about it. Understanding how the repository is different from the working directory is crucial. A few clif notes: * You create a repository in an empty directory. This repository is separate and very different from the data you actually work on. In our case our repository is in /swdev/cvsroot. This is what the CVSROOT environment variable is set to. * You use ONLY cvs commands to get data into and out of the repository. Ideally you'd never directly touch the repository data. * You work in a separate working directory (off of your home directory probably, in my case /home/derosier/projects) and you check out your source code modules there. When you've made some changes you want to check in, you do a 'cvs commit' command. * Even if you run CVS locally, think of it as a server. It's a black box where you store things. You make requests to get data out, work on it, and then make a request to store data back in. From an OOP point of view: It is encapsulated data with a very well defined interface or API. Use the interface, don't touch the data. * If the above doesn't make sense to you, then read it again, read the CVS manual again until it makes sense. Do not try to setup and use CVS without understanding this. Hope this helps, - Steve David Wood wrote: You need to spend some time with the manual, and/or the various tutorials on the subject. As you are discovering, if you're not understanding the manual, forging ahead anyway may not be the best decision. A repository is a database (that holds its data in RCS files - ending in .v). You create a repository in an _empty_ directory, somewhere separate (with cvs init), and then you import sources into it from wherever you have them (with cvs import). Then you do a cvs checkout to create a new CVS working directory from the repository - and that is where you then do your work. (Often people will move or zip the original directory they imported from, and then move their CVS working directory into its place.) You've created a repository right on top of where you are working, which is bad. I confess at this point I'm not sure what you've got in those files (perhaps someone wiser than myself can offer a shortcut?), but my best guess is that it will be easier to recover from backups than to reconstruct your sources from what's left of them now (.v.v files). At any rate, since you have backups, there is no reason to panic. In the future, just put your repository somewhere separate (/home/cvs/repository ?). And of course, have another go at the manual (or some of the other reading materials) to get a better handle on how the system works. John Wards [EMAIL PROTECTED] wrote on 11/26/2003 12:25:42 PM: On Wednesday 26 November 2003 4:57 pm, David Wood wrote: First, did you work for 18 months on something without making backups? Yes yes of course, but they are not with me currently and I am in a bit of a panic! Second, to get help you will need to be much more specific about exactly what you did when you figured out how to make a repository from your original source files. How did you set everything up (CVSROOT, etc)? What commands did you run? It sounds like you have some confusion about repositories versus working directories and the import process. Did you read the CVS manual before you started? I fear from your description you've gone pretty far down the wrong way. Yes I read the manual and I should have probably been a bit more detailed but I thought ah someone wil know an easy undo comand.seems not then :-( I got a bit confused with all the CVSROOT
Re: CVS admin
How do I set-up my self as a cvs admin on the server side? What do you mean by cvs admin? As a CVS administrator, you should have full permissions on the repository or repositories. To use cvs admin commands, either have no Unix group cvsadmin, or be a member yourself. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
pretty printer on commit
I would like to run all commits of .h and .cc files through a pretty printer to automatically assist in later merges and conformance to style. I'm running a pserver. Are there any tips I should know of how to do this before trying? Thanks, Dave. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS merge
I think the problem is the start and end points of your merge. If I have a trunk, and I created a branch from that trunk, tagging it at the point it was created, I would use the following to merge the branch back into the trunk: -j branch_CREATED -j branch Often this can simply be abbreviated as -j branch If you are doing something more complicated than this, please tell us the structure of the branches involved. There are additional details on this subtle and complex feature here, in the manual under the Branching and Merging section: http://www.cvshome.org/docs/manual/cvs-1.11.7/cvs_5.html#SEC54 I advise you to read it carefully, or you will get into trouble. [EMAIL PROTECTED] wrote on 11/11/2003 09:23:19 PM: Hi, I don't think my following merge result is correct. I did a merge in branch1 to join branch2 as following command: branch1$ cvs -q update -Pd -kk -j branch1 -j branch2 There is only one file shown me the conflicts by and comments embedded in the file. Many other files in branch1 are simply replaced by branch2 source files and created .#file1.h.1.2.3, .#file2.c.1.2.5 For example, the file1.h in branch1 includes three functions A(), B() and C(). The file1.h in branch2 has only two functions A() and B(). I expected that the merged new file would include A(), B() and C(), but to be surprised, the new merged file has only A() and B(), same as branch2 source file. The function C() was simply lost. Is this normal behavior or am I missing something here? (CVS version 1.10 for Window, I guess, it is irrelevant) Thank you. yh __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ 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: Can't create a module in cvswin1.13
Do you have a log of what happened during the import, and during your attempt to check out? How are you setting your CVSROOT, in an environment variable, or on the command line? Are you using the command line cvs, or wincvs (etc)? [EMAIL PROTECTED] wrote on 11/11/2003 02:52:07 PM: Dear All: I wasn't able to create a module in my local repository. I followed the instruction verbatim! I am running from a local drive and once I imported an emty or populated directory, I can't check it out locally?? It keeps telling me the Module name can't be found? I ran the Admin command Get the cvs modules But cvs tells me theat No module entries found! Consult your repository's admin. What could have done wrong!! Thanks, __ Do you Yahoo!? Protect your identity with Yahoo! Mail AddressGuard http://antispam.yahoo.com/whatsnewfree ___ 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: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 04:37:03 PM: I see it now, and I thought that the conflicts you now say don't occur were the ones you objected to in the first place. Not at all. The conflicts that troubled me were happening because I was double-merging (when bringing B back to the trunk, merging from 1-4 instead of 2-4), _until_ I used the technique laid out in that email. The conflicts in question are what you describe, here: If A branched first, then 2-4 will attempt to remerge changes made to the trunk between the base of A and the base of B, causing the same sort of spurious conflicts you were attempting to avoid. And that did not seem to be true. It seemed to me that those changes are not merged twice - as I said, The changes between the start of A and the start of B are not in A, and they are inherent in B. So I am wondering if I tested it wrong and am thinking about it wrong? Regardless, some of what you said in that email was correct and some wasn't, but I don't think you can solve the general case without saving a merge history for each revision of each file. If individual files can't merge, and only whole branches can, I confess I don't understand why that is true, unless by saying the general case we are actually discussing something different than I imagine. One other thing I was wondering about was what I found when experimenting with the approach you suggest (using multiple merges): that conflicts arise during the interim steps, making the process unworkable. I am interested in single-step merges both because it _seems_ possible generally to construct one appropriate to a given case, and because they appear to me to avoid the issues of conflicts during interim merge steps. It isn't. The existing GCA algorithm is merely a convenience to avoid typing a start-revision in the most common case (merging from a branch to its parent) and I think it actually confuses more people than it Let me clarify what I mean a bit more. I want to generalize the process of finding a merge start point based on merge and branch information. I think the CVS GCA system is an interesting approach when working with branch information alone. If I understand it correctly, it is analogous to walking backwards up the ancestry of the source branch, searching for the most recent branch point on any common parent, of the souce or the destination branch (whichever is older). What I am experimenting with is the notion that if you add merge information to the mix, this approach still works. I am gathering that you don't think it will; but I guess what I am wondering, in that case, is, how will it fail? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/06/2003 08:57:22 AM: The way to avoid only processing this for whole branch merges is to track individual commits as change sets. For example, store that the sum of changesets for file1 1.2 - 1.2.4.7 have been merged into the trunk. Then later, if a merge is attempted from 1.1 through 1.2.4.103.2.17, CVS could notice that the changesets above lay in the path and merge 1.1 - 1.2 1.2.4.7 - 1.2.4.103.2.17 as two separate merges. If 1.2.4.103.2.1 - 1.2.4.103.2.10 has already been merged as well, then that could be subtracted as well, leaving CVS with three merges: ~1.1 -1.2 ~1.2.4.7 - 1.2.4.103 ~1.2.4.103.2.10 - 1.2.4.103.2.17 and so on. I'm curious, do you think that multi-step merges will be required for the general case? Did you see my response to your original email? You had thought that multiple merges were necessary for that example, but when I studied it it didn't look that way. http://mail.gnu.org/archive/html/info-cvs/2003-11/msg00053.html Isn't it possible that, if I do whole branch merges, I can handle everything with single merge operations... subject to caveats: No, I don't think there is a general way to handle this. Or, at least the general way is to allow the user to pass a switch or somesuch to override the smart behavior so the merge can be reapplied. Note that this requires that CVS report when it skips portions of a requested merge so that the user will know this is necessary. Certainly that switch is assumed. But say for the sake of argument that it is all or nothing. In other words, if you want to use the smart merges, you have to follow the smart merge rules. That merely means doing some things a bit differently; for instance, if you want to use merge as a tool in more unconventional ways (I want to re-merge this branch because changes from it were accidentally deleted), you have to find other solutions. In the case of this example, I'd envision using the conventional merge operations to easily simulate undoing the mistake without additional complexity. |My cursory examination of CVS's GCA algorithm leaves me with the |impression that it relies on properties of the revision numbering system, |which if true makes it abundantly clear why there is no simple path to |making CVS smarter about GCA, even if it did have the information about |merge activity that it needed. No, this would not make CVS smarter about GCA. This would make CVS smarter about merging. Please do not misuse the term GCA this way. GCA has a well-defined meaning and well-established usage in CVS and the algorithm we are discussing has little to do with determining the ancestor, except possibly for determining an implicit start point for a merge request, which is exactly how the GCA is used currently. I will be careful not to confuse the term GCA with any new, more automated system for determining merge start points. I meant to draw the comparison only because what I envisioned for such a new system seemed functionally very similar to the existing CVS GCA algorithm (in function, of course, not in implementation). Or am I wrong even in this? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Please correct me if I'm wrong. I _think_ this is the greatest common ancestor problem. And finding one is actually something CVS does for you - on the first mege (with a single -j). Which is usually OK in cases where a branch immediately dies (i.e. becomes dormant) afterwards. The problem is that CVS does not remember that a merge took place. After a merge, the map of ancestry that was built by branch operations is no longer correct. And from that point on, CVS relies on _you_ to find the GCA. [EMAIL PROTECTED] wrote on 11/05/2003 03:55:38 AM: Is it just me, or is this getting way too complex to be usable except by CVS experts? I thought I was comfortable with the issues surrounding branches and merges, even though we are not using branches yet here. But I don't understand half of what you folks are saying. Worse: in my understanding this isn't even a particularly complex case. Let me see if I have this right. You want to merge changes made on a branch back into the main development stream, then merge that with the changes on another branch. Surely **everyone** will need to do this, sooner or later? Andy Jones. At 03:37 am 5/11/03, David Wood wrote: I am not sure about something. |If branch A and branch B in your example don't branch form the same |point on the trunk, a merge from point 2 to point 4 into the trunk might |still not do what you want. If branch B branched first, then 2-4 may |back out changes made to the trunk between the base of B and the base of |A. If A branched first, then 2-4 will attempt to remerge changes made |to the trunk between the base of A and the base of B, causing the same |sort of spurious conflicts you were attempting to avoid. Assume B is branched first. A merges to the trunk. Then A merges to B. Then B merges to the trunk as well. I think the trick here is what happens when A merges to B. If you do that merge like this: (in B's working dir): cvs update -j branchA_CREATED -j 3 (3 == where A merges to B) then you are correct. This merge will be missing changes from between the start of B and A - ALREADY! In other words, with respect to B, part of A was left out, since it was created before branchA_CREATED - on the trunk. But I think this is really the wrong way to merge A into B. The right way is to do it would be to say: cvs update -j branchB_CREATED -j 3 Then branch B does indeed end up incorporating everything from branch A. In other words, the changes on the trunk after B was created until A starts, and then all then all the changes in A. So when doing that kind of merge, always use the newest common ancestor (in this case, the start of B). Now let's look at your other scenario. When A is created before B, everything else being equal, I did not receive spurious conflicts doing that last merge in a single step (2-4, Jamie's way) after all! You say there should be, because that I am remerging changes made to the trunk between the base of A and the base of B. But I can't see where the redundancy should come from. The changes between the start of A and the start of B are not in A, and they are inherent in B. So goes my theory. Perhaps we are making different assumptions? |The only clean way to do this in the general case is to tag branch B |before and after your merge from A at point 3 and merge B back into the |trunk as two merges: | |~cvs up -j 1 -j pre-3 |~cvs up -j post-3 -j 4 ... Oops, yes, you are correct. What I said was correct if point 2 3 were the same (at point 2 all of branch A was merge to both the trunk and branch B). A clean merge to the trunk without conflicts from a repeated merge with distinct points 2 3 would require the two commands I listed above and a third merge: ~cvs up -j 2 -j 3 So if I understand you all correctly, a generalized merge formula would be: cvs update -j start-of-branchB -j pre-3' cvs update -j 2 -j 3 cvs update -j post-3' -j 4 in that order? What if branchB had made changes that would conflict with branchA's changes, and the merge from A to B is to correct that conflict and bring B into sync _before_ it merges with the trunk? Following this pattern, I will still get that conflict between B and the trunk on the first command - even though those conflicts had already been resolved post-3'. Nothing subsequent would work without manually duplicating the conflict resolution already present in B... ___ 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 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 10:38:02 AM: No. The GCA has not changed and CVS determines it correctly. You simply no longer wish to merge from the GCA forward because some of those changes were already merged to your destination (from another branch and at your own request - CVS did nothing wrong) and you wish to avoid conflicts. I am not saying CVS is doing anything wrong; I think it is following its design precisely. I think my problem may be with terminology. If I merge from a child to the trunk, and then I later merge it again, what is the greatest common ancestor on that second merge? Still the beginning of the child? Or is it now point of the first merge? It sounds like you are saying the former - following the strict CVS definition for GCA, that is right. But what about an alternate definition of ancestry based on both branches _and_ merges? Right now to do that second merge I have to tell CVS where to start - it no longer uses its GCA algorithm to figure that out for me. But I am telling it the new common ancestor myself - the point of the previous merge (as opposed to the point of the branch). Isn't this an analogous process to CVS' current GCA? ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
Derek Robert Price [EMAIL PROTECTED] wrote on 11/05/2003 12:43:14 PM: Greatest Common Ancestor, or GCA, is a term that refers to the RCS revision structure and always means the more recent revision two revisions have in common, often a branch point, but in the case of a branch of a branch and the trunk, note that the GCA is on the trunk, not the base revision of the branch, but the base revision of its parent. So in other words, you are saying: in the case where the branch (child) of a branch (parent) merges back to the trunk (grandparent), the GCA is on the grandparent, at the point where the parent begins. Right? CVS determines GCA when you only specify one revision in a merge as a convenience for the common case, merging from a branch into its parent. This does not mean that the first revision of a merge specification should always be called a GCA. Yes, it would be convenient if CVS were smart enough to track what data has already been merged to various locations and attempt to intellegently exclude these data sets in following merges. This has been suggested many times in the past. In practice, CVS does not currently keep track of the necessary data and even if it did, the problem is a very hard one. There _are_ reasons a user could wish to specify a merge twice. They accidentally copied old files over the new ones which had contained the merge; another developer removed the merge changes by hand and committed in conjunction with code you do not want removed. etc.Basically, CVS would have a hard time tracking what you manually did to its merge result. If someone were to solve this problem and submit a patch that implemented the solution including documentation and tests cases which addressed these sorts of issues and any others that arose, believe me, I would be one of the first to vote that CVS incorporate the code. I am hopeful that someone will be me. My initial approach has been to use a wrapper which executes branches and merges, generating and applying tags in addition to branching and merging, and maintaining extra state data in a database. I believe that the tool has all of the necessary information available; the question now is using it to determine the correct merge start point in a general way. I only intend to support whole branch merges, and I have been under the impression that I can focus solely on eliminating over- and under-merging. I believe cases such as your examples, where it is desirable to double merge, or to deliberately eliminate part of the merge, cannot be handled in a general way - although perhaps you will disagree? My cursory examination of CVS's GCA algorithm leaves me with the impression that it relies on properties of the revision numbering system, which if true makes it abundantly clear why there is no simple path to making CVS smarter about GCA, even if it did have the information about merge activity that it needed. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Rephrasing: question about merging branches
Let me try to put it another way. I have a parent branch, and it has two child branches. If I want one child to merge to the parent, and then to the other child, how does that other child later merge to the parent as well? Is it (on the parent): update -j first_child_merge_point -j second child If so, what happens to changes from before the first_child_merge_point? -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Rephrasing: question about merging branches
I would say your ascii graphic is admirable! What you are saying matches what I'm seeing in tests, and I think I get it now. I believe my problem has been a silly confusion with the way update -j -j works. I understand a merge between 1 and 4 (and for that matter, a reverse-merge between 4 and 1) well enough. Essentially, I mistakenly envisioned a merge between 3' and 4 - rather than 2 and 4. Hence my fear about loss or mistreatment of changes before the child-to-child merge. I think what all this means is that branchB is now essentially merging against branchA (having received common chagnes by, and resolved conflicts with) branchA... and the merge delta with the trunk must now use branchA (at point 2) as a reference point in order to correctly reflect changes against the trunk. It is potentially confusing, but you have made it seem very simple. Thank you! -David Jamie Wellnitz [EMAIL PROTECTED] wrote on 11/04/2003 11:50:35 AM: Sorry for the ascii graphic in advance . . . If you have (* indicates merge point): branchA and branchB originated from trunk at point 1. branchA merged to trunk at point 2 on branchA and 2' on trunk. branchA then merged to branchB at point 3 on branchA and 3' on branchB. Now, we want to merge branchB (point 4) to the trunk (4'). branchA 23 /-\-\ 1 / \ \ 4' trunk --* \ -* \2' \/ \---*--/-- branchB 3' 4 I think you want the common ancestor of the current branchB tip and trunk tip. That would be point2 on branchA. (This is assuming you did a full merges, not just a few changes, from A-trunk and A-B.) So assuming you put tags down to keep track of the merge points, you might try (on the trunk): cvs update -j point2 -j point4 It looks like my point2 is your first child merge point and second child is the tip of branchB (where you put a tag before the merge). Which changes before the first child merge point are you wondering about? Thanks, Jamie Wellnitz [EMAIL PROTECTED] On Tue, Nov 04, 2003 at 11:06:44AM -0500, David Wood wrote: Let me try to put it another way. I have a parent branch, and it has two child branches. If I want one child to merge to the parent, and then to the other child, how does that other child later merge to the parent as well? Is it (on the parent): update -j first_child_merge_point -j second child If so, what happens to changes from before the first_child_merge_point? -David ___ 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: Rephrasing: question about merging branches
I am not sure about something. |If branch A and branch B in your example don't branch form the same |point on the trunk, a merge from point 2 to point 4 into the trunk might |still not do what you want. If branch B branched first, then 2-4 may |back out changes made to the trunk between the base of B and the base of |A. If A branched first, then 2-4 will attempt to remerge changes made |to the trunk between the base of A and the base of B, causing the same |sort of spurious conflicts you were attempting to avoid. Assume B is branched first. A merges to the trunk. Then A merges to B. Then B merges to the trunk as well. I think the trick here is what happens when A merges to B. If you do that merge like this: (in B's working dir): cvs update -j branchA_CREATED -j 3 (3 == where A merges to B) then you are correct. This merge will be missing changes from between the start of B and A - ALREADY! In other words, with respect to B, part of A was left out, since it was created before branchA_CREATED - on the trunk. But I think this is really the wrong way to merge A into B. The right way is to do it would be to say: cvs update -j branchB_CREATED -j 3 Then branch B does indeed end up incorporating everything from branch A. In other words, the changes on the trunk after B was created until A starts, and then all then all the changes in A. So when doing that kind of merge, always use the newest common ancestor (in this case, the start of B). Now let's look at your other scenario. When A is created before B, everything else being equal, I did not receive spurious conflicts doing that last merge in a single step (2-4, Jamie's way) after all! You say there should be, because that I am remerging changes made to the trunk between the base of A and the base of B. But I can't see where the redundancy should come from. The changes between the start of A and the start of B are not in A, and they are inherent in B. So goes my theory. Perhaps we are making different assumptions? |The only clean way to do this in the general case is to tag branch B |before and after your merge from A at point 3 and merge B back into the |trunk as two merges: | |~cvs up -j 1 -j pre-3 |~cvs up -j post-3 -j 4 ... Oops, yes, you are correct. What I said was correct if point 2 3 were the same (at point 2 all of branch A was merge to both the trunk and branch B). A clean merge to the trunk without conflicts from a repeated merge with distinct points 2 3 would require the two commands I listed above and a third merge: ~cvs up -j 2 -j 3 So if I understand you all correctly, a generalized merge formula would be: cvs update -j start-of-branchB -j pre-3' cvs update -j 2 -j 3 cvs update -j post-3' -j 4 in that order? What if branchB had made changes that would conflict with branchA's changes, and the merge from A to B is to correct that conflict and bring B into sync _before_ it merges with the trunk? Following this pattern, I will still get that conflict between B and the trunk on the first command - even though those conflicts had already been resolved post-3'. Nothing subsequent would work without manually duplicating the conflict resolution already present in B... ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
checkin comments between tags
Title: checkin comments between tags How do I get a list of all the checking comments between 2 labels (or since the last label). -Dave David E. Muller Configuration Manager Overture Services, Inc. www.overture.com Office: 760.476.6406 Mobile: 760.458.2714 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Conflict committed
I just found that one of the developers here has managed to commit a file with a conflict in it. I had been under the impression, based on documentation and past experience, that it was impossible to commit a file with conflict markers inside it. However, I just witnessed this. Are my assumptions about this mistaken? What circumstances allow unresolved conflicts to be committed back to the repository? -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Conflict committed
Thank you for the advice about commitinfo. I believe we will do exactly that as a safeguard against future problems. I totally respect that CVS should be content agnostic, although I did have to rename my cvs java package to cvsutil because you can't have dirs named cvs in the repository... It's too bad such a safeguard can't be offered as a kind of optional-but-default condition. Common case, etc. [EMAIL PROTECTED] wrote on 10/29/2003 12:07:28 PM: The timestamp of the file being changed will let the file with conflicts be committed with just a warning. Some folks consider it useful to check for conflict markers in their commitinfo scripts and refuse the commit. It is not up to cvs to determine what data patterns should or should not be allowed to be committed into a file. -- Mark Example: % cd /tmp % mkdir testit % cd testit % cvs -d /tmp/testit/cvs-testrepos init % cvs -d /tmp/testit/cvs-testrepos co CVSROOT % cd CVSROOT/ % (echo aaa; echo bbb; echo ccc) file1 % cvs add file1 % cvs ci -mnew file1 % echo ddd file1 % cvs ci -madd file1 % echo eee file1 % cvs up -j1.2 -j1.1 file1 % cat file1 aaa bbb ccc file1 ddd eee === 1.1 % touch file1 % cvs ci -mconflict file1 cvs commit: warning: file `file1' seems to still contain conflict indicators Checking in file1; /tmp/cvs-testrepos/CVSROOT/file1,v -- file1 new revision: 1.3; previous revision: 1.2 done cvs commit: Rebuilding administrative file database % -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.3 (FreeBSD) iD8DBQE/n/PQ3x41pRYZE/gRAqT1AKDVi92UQJZorCK47WNQcrSBtFPWOACg3T1T b6nolaHXENd1+/R0jqRIxZY= =k4nC -END PGP SIGNATURE- ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Commit Error and Checkout Error
Hi, I am able to login into Cvs as root as well as a user. when I have logged in as a root i face some difficulties when trying to commit a file after making changes to the file.It says root is not allowed to commit files. Right; root is not allowed to commit files. This is a design feature, intended to increase the accountability of changes. Since root is often a shared account (it's a functional account rather than a personal one), allowing it to check in would make it impossible to determine who checked a change in. (It isn't quite this simple; if CVS is able to determine who root really is, CVS may allow the checkin.) when i am logging as a user i am unable to checkout the files. It says permission denied . That would mean that your user account does not have the permissions necessary. Your account must have read permission on all files and directories you are going to use, execute permission on all directories, and normally write permission on all directories. (It is possible to get around this, for read-only access, by setting LockDir in CVSROOT/config.) -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Procedural ways of using CVS.
The approach centers around an enhanced version of the ant CVS Task that is used to create branches and conduct merges. It stores information about branches and tags in a database, and applies it to create the appropriate CVS commands. In practice this custom Task is used twice. The first time, it gets the destination branch into the working directory, tags the source branch (according to a uniform naming convention), and does the update [-j previous-merge-tag] -j current-merge-tag. The output of that operation is watched by what has grown into a slightly complex parser whose job is to flag conflicts. Then you'd do your build and any other tests you want to do. The second use involves committing the merge and tagging the destination branch. [EMAIL PROTECTED] wrote on 10/17/2003 02:51:30 PM: David, Read through your procedure, was quite interesting. Can you tell some more details about ANT and CVS coordination with respect to tagging, merging etc. Thank you. |-+--- | | David Wood | | | [EMAIL PROTECTED] | | | Sent by:| | | info-cvs-bounces+adabalap=schneider.| | | [EMAIL PROTECTED] | | | | | | | | | 10/17/2003 10:50 AM | | | | |-+--- -- | || | To: [EMAIL PROTECTED]| | cc:| | Fax to:| | Subject: Re: Procedural ways of using CVS.| -- | I'll share what I've developed; it may be helpful to you and helpful to me as well, if anyone has comments. Keep in mind that every situation may require a different approach to CVS, and ours is _not_ the most common usage pattern (the most common, I think, focuses on systems or application software development, and that does get some anecdotal treatment in the manual). In my case the job is managing ongoing development of a running Java web application. There are a number of parties who work on various aspects of it in parallel, some off-site. There are generally changes being developed, tested, and ready for deployment simultaneously at a given time. We maintain staging and production branches. The current production branch matches exactly what is deployed at all times. The staging branch is the same, except that it receives new code for testing before it goes to production. Projects happen on Project branches that fork from production when they begin, and merge to staging and then production for testing and deployment. A project may be continuous, or short-lived. If it lives a long time, other changes from the production branch since the fork may be subsequently merged into it. People may share a project, or they may use it alone. We use custom Java code, primarily in several custom ant tasks, to manage merges and the associated tagging automatically, and to integrate this process seamlessly with other aspects of our build and delpoyment process. With one ant task, we can merge, build, and commit that merge if there are no compile errors or conflicts (which we force users to resolve in advance), and then actually push changes to staging and production. It's easy to maintain good logging this way (ant's record task), another bonus. I'm quite pleased with ant's CVS support, and with ant in general. The assumptions in this approach work well for us because our application is fairly compartmentalized. In our case it's important not just to be able to separate out changes by user or project, but to be able to easily put them in (or take them out) of production without affecting other work going on in parallel. Most of all, it's important for us to not have a mystery about what should go in and what shouldn't when it's time to make a new production build (which may happen very frequently), although certainly not every 30 minutes. :) [EMAIL PROTECTED] wrote on 10/17/2003 02:22:53 AM: I'm interested in how people organise their in-house projects from an administrative point of view with CVS, for example, when they use branching, tagging and how (or if) they use CVS with ant, anthill and how they manage frequent builds and releases (ie, every 30 minutes) There is a brief amount of information in the cvs book (Open source dev with CVS), but I'm looking for websites or peoples own opinons on how they structure their in house
Re: Procedural ways of using CVS.
I'll share what I've developed; it may be helpful to you and helpful to me as well, if anyone has comments. Keep in mind that every situation may require a different approach to CVS, and ours is _not_ the most common usage pattern (the most common, I think, focuses on systems or application software development, and that does get some anecdotal treatment in the manual). In my case the job is managing ongoing development of a running Java web application. There are a number of parties who work on various aspects of it in parallel, some off-site. There are generally changes being developed, tested, and ready for deployment simultaneously at a given time. We maintain staging and production branches. The current production branch matches exactly what is deployed at all times. The staging branch is the same, except that it receives new code for testing before it goes to production. Projects happen on Project branches that fork from production when they begin, and merge to staging and then production for testing and deployment. A project may be continuous, or short-lived. If it lives a long time, other changes from the production branch since the fork may be subsequently merged into it. People may share a project, or they may use it alone. We use custom Java code, primarily in several custom ant tasks, to manage merges and the associated tagging automatically, and to integrate this process seamlessly with other aspects of our build and delpoyment process. With one ant task, we can merge, build, and commit that merge if there are no compile errors or conflicts (which we force users to resolve in advance), and then actually push changes to staging and production. It's easy to maintain good logging this way (ant's record task), another bonus. I'm quite pleased with ant's CVS support, and with ant in general. The assumptions in this approach work well for us because our application is fairly compartmentalized. In our case it's important not just to be able to separate out changes by user or project, but to be able to easily put them in (or take them out) of production without affecting other work going on in parallel. Most of all, it's important for us to not have a mystery about what should go in and what shouldn't when it's time to make a new production build (which may happen very frequently), although certainly not every 30 minutes. :) [EMAIL PROTECTED] wrote on 10/17/2003 02:22:53 AM: I'm interested in how people organise their in-house projects from an administrative point of view with CVS, for example, when they use branching, tagging and how (or if) they use CVS with ant, anthill and how they manage frequent builds and releases (ie, every 30 minutes) There is a brief amount of information in the cvs book (Open source dev with CVS), but I'm looking for websites or peoples own opinons on how they structure their in house development with CVS. There have already been questions (and answers) like this in the mailing list. I don't know the topic anymore but if you browse the archive you may find some good descriptions, sometimes with links to more info. bye Fabi ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS refuses to remove (branch) tag
By default, since 1.11.2, CVS refuses to delete and move branch tags unless you tell it you know that you are disturbing a branch tag using the `-B' option to tag or rtag. This is because disturbing branch tags is usually a VERY VERY VERY etc. bad idea. FWIW, if CVS had done that in 1.10.7 it would have saved me a lot of pain back when that was current, and would not have interfered with our operations in the slightest. I think this is a really good change. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Stale lock files with anonymous CVS
We have a CVS repository here where some users have read only access except in a few directories, and the rest have read-write access everywhere. This does work as advertised, except that when a read-only user attempts to put a file where they shouldn't, we end up with a stale lock. Then no one can use the repository until it's manually removed. It seems that when the CVS process on our (Solaris 9) server has a permission problem, it dies without removing its lock files. FYI, we are using a seperate lock directory. When CVS dies it gives the error: cvs commit: ERROR: cannot write file /opt/cvs/repositories/primary/myproject/test/Attic/testfile2.html,v: Permission denied Terminated with fatal signal 11 The read-write users map to user CVS. Read-only users map to user CVSR. Both belong to group CVS Most files are rwx for user CVS, and r-x for group CVS. Directories where read-only users can write are rwx for user CVSR, and rwx for group CVS. I haven't found any information about this kind of problem over several days of searching. Given that the very popular anonymous CVS repositories around the world must use a similar technique, and such a condition would make them notoriously abusable (i.e. trivial, evil DOS attack), I assume I must be doing something wrong. Does anyone have any ideas? Thanks, -David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pserver never starts running
Hello all,
I am having trouble with my cvs remote login. It appears that my
pserver doesn't start running.
Under what circumstances?
My OS is Redhat 9.0
It is running xinetd
My /etc/xinetd.d/cvspserver file looks like this
# default: off
# description: An internal xinetd service, listing active services.
service services
{
disable= no
id= cvspserver
env= HOME=/home/cvs
port= 2401
socket_type= stream
protocol= tcp
wait= no
user= root
passenv=
server= /usr/bin/cvs
server-args= --allow-root=/var/lib/cvsroot pserver
}
When I type:
telnet [host] 2401 from my windoze machine is says: Connection to
[host]...Could not open a connection to host on port 2401 : Connect
failed. ([host] is either jake or 192.168.0.155)
Have you rebooted or anything since putting this in cvspserver?
Or typed
kill -SIGUSR2 xinetd
as root, to get xinetd to reread its configuration files?
If you've done either of these, then I don't know what could be
going on.
David H. Thornley| If you want my opinion, ask.
[EMAIL PROTECTED] | If you don't, flee.
http://www.thornley.net/~thornley/david/ | O-
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs-1.11.7 seems to have changed the api for release
On Thu, Oct 02, 2003 at 03:32:43PM MDT, Derek Robert Price wrote: ~From the NEWS file: | Changes from 1.11.6 to 1.11.7: . . . | * The global '-l' option, which suppressed history logging, has been removed | from both client and server. DOH!! I read that but didn't put two and two together...thanks for helping me throught my brain problems. :) ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs-1.11.7 seems to have changed the api for release
Using pserver cvs-1.11.7 on solaris and client cvs-1.11.6 for aix, hpux, or solaris, there is this problem which does not occur when the client and server are the same version: cvs release -d example Protocol error: bad global option -l cvs release: unable to release `example' Thanks, Dave. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: Stable CVS 1.11.7 Released! (Derek Robert Price)
Under cvs-1.11.7, the password is displayed on the client screen as follows: cvs login (Password is not displayed while typing it, but is displayed after pressing the ENTER key.) I know pserver in general is not very secure, but is there any way to have a patch or fix that might eliminate this display? Thanks, Dave. -- http://agilemanifesto.org/principles.html () ascii ribbon campaign - against html mail /\- against proprietary attachments For assistance, see: http://www.expita.com/nomime.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Stable CVS 1.11.7 Released! (Derek Robert Price)
On Tue, Sep 30, 2003 at 03:10:08PM MDT, Larry Jones wrote: David Everly writes: (Password is not displayed while typing it, but is displayed after pressing the ENTER key.) On what platform? -Larry Jones All three have the same behavior of showing the password (which was not present with 1.11.6). Output of uname -a: AIX chanegw0 3 4 000110554C00 SunOS ndccsr02 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-Enterprise HP-UX chanhp9 B.11.11 U 9000/800 1877750441 unlimited-user license Configure parameters: ./configure --prefix=/opt/cvs-1.11.7 --without-krb4 --without-gssapi I am assuming this has something to do with the new internal getpass function...but not sure what. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
[lawrence.jones@eds.com: Re: Stable CVS 1.11.7 Released! (Derek Robert Price)]
Thanks Larry! This fixed it.
---BeginMessage---
David Everly writes:
All three have the same behavior of showing the password (which was
not present with 1.11.6). Output of uname -a:
AIX chanegw0 3 4 000110554C00
SunOS ndccsr02 5.8 Generic_108528-19 sun4u sparc SUNW,Ultra-Enterprise
HP-UX chanhp9 B.11.11 U 9000/800 1877750441 unlimited-user license
By golly, so they do. The GNULIB version of getpass is defective, but
it doesn't show up on my BSD-derived system nor, presumably, on Linux.
Since passwords are read directly from the terminal, it's not tested in
the nightly testing. I've checked in a fix and I'll be sending it on to
the GNULIB folks. Here's a patch for anyone that wants it:
Index: getpass.c
===
RCS file: /cvs/ccvs/lib/getpass.c,v
retrieving revision 1.1.2.1
retrieving revision 1.1.2.2
diff -u -r1.1.2.1 -r1.1.2.2
--- getpass.c 29 Jul 2003 13:37:37 - 1.1.2.1
+++ getpass.c 30 Sep 2003 22:11:51 - 1.1.2.2
@@ -20,6 +20,9 @@
#endif
#include stdio.h
+#ifndef SEEK_CUR
+#define SEEK_CUR 1
+#endif
#include termios.h
#include unistd.h
#include getline.h
@@ -83,8 +86,11 @@
/* Remove the newline. */
buf[nread - 1] = '\0';
if (tty_changed)
- /* Write the newline that was not echoed. */
- putc ('\n', out);
+ {
+ /* Write the newline that was not echoed. */
+ if (out == in) fseek (out, 0, SEEK_CUR);
+ putc ('\n', out);
+ }
}
}
-Larry Jones
I sure like summer vacation. -- Calvin
---End Message---
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change
On Tue, 2003-09-09 at 14:53, Greg A. Woods wrote: [ On Tuesday, September 9, 2003 at 10:10:46 (-0400), Tom Copeland wrote: ] Subject: Re: Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change Hm. Do CVS branches not work right with binary files? It depends on what you mean by work. Merging branches containing binary files is one heck of a lot more work. Cool, yup, right, merging binary files isn't going to happen. Isn't going to happen with any other version control system I know of, either, which is why I don't see why CVS should be bad for binary files. It isn't going to buy you much over a simpler solution, but I don't see that it will cost anything, assuming that CVS is already set up. I wouldn't use CVS just to store binary files, but I would and have happily used it to store binary files associated with text files. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Countering the usual diatribe against binary files, was Re: cvs diff, proposal for change
Greg A. Woods wrote: 1. keep your binary files in a separate manually managed archive. ... CVS supports binary files?!?!?!? No, I don't think so. The '-kb' sticky flag is just a terribly bad hack that gets more people into more trouble with CVS than you could ever imagine because it gets mis-interpreted as doing what you think it does. It was not intended for that purpose at all and it does not work the way you think it does. DO NOT try to store binary files in CVS. [EMAIL PROTECTED] wrote: We are currently storing gigabytes of binary data files in our CVS repository along with lots of text data. We have found that if you remember to cvs add -kb from Windows (mandatory) or Unix (recommended), or to mark the files as binary after check-in under Unix *before* the first-ever modification is made, it can cope. At the cost of performance penalties. But reading the above I'm wondering whether there's some other danger that we're unaware of, that would make us change our current methods. I've read the FAQ section on binary files, and found nothing there that I/we weren't already aware of. We have several terabytes of binary files stored in a CVS repository. Whether it be a terrible hack, or a misuse of the tool, it seems to work sufficiently well to get the job done. We are not interested in merges, or diffs, or concurrency, we just want the versioning and the log of who, what, when and why that lives in the ,v files. We don't care that inside they are not stored as deltas, we don't care that each version is stored as all bytes in their entirety, we just keep buying more shelves of disks in the arrays. It would be nice if it were faster, but it is fast enough to meet our requirements. Going back to doing this manually would be a nightmare, a totally untenable suggestion bordering on ludicrous. Until there is a good, free, binary file version control system, then cvs, with all its known limitations, fits the bill. The -kb flag is the greatest thing since sliced bread, apart from the long forgotten versioning file system of VMS that might also have been a suitable solution for us. If there is something undesirable going on inside CVS that is problematic, I would be interested to know, but the empirical evidence would tend to suggest otherwise. david PS. With respect to the original thread, since our binary files are a) of a specific format, and b) we have tools equivalent to diff that do comparisons of the content (for the purpose of human comparison but not automatic editing or patching), yes it would be nice to be able to parameterize or configure the type of diff used, without any expectation that there would be any corresponding storage using deltas inside, if these two operations are indeed separable. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pserver handle multiple requets?
hi, can pserver handle multiple requests(say 15 - 20) at the same time? Always did whan I was administering it. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Checking out without lock
I have read access to the CVS repository but no write access. Obviously this means I cannot commit any changes. But it ought to be possible to get a checkout. However even if I turn off history logging, cvs co won't work because it wants to make a lock file. Is there some option similar to -l to say do not make lock files when reading? This means you could get an inconsistent checkout when someone updates the repository while you're reading, but that is a risk anyway for projects with more than one directory, and a risk I'm willing to take. Not that I know of. The correct solution is for the administrator to set up separate lock directories, with a line like LockDir=/usr/cvs/cvslocks in the CVSROOT/config file. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Cannot add file on non-branch tag
Hi All I am trying to add a file on a following specific path on a branch named bname Though I am able to add a file on some other location path. The error is - cvs server: cannot add file on non-branch tag bname I have checked the other files existing on this path are branched, infact added after branching. It would appear that bname is not a branch on that particular file, but rather a revision tag. CVS maintains information by file, and so it is entirely possible (and usually a problem) to have a tag be a branch tag on one file and a revision tag on another. You can check this with cvs stat -v filename, which will show you all the tags and whether they are branch or revision. (You can do the same with cvs log, but it's harder to spot the difference.) To fix this, eliminate the existing bname tag, and recreate it as a branch tag. Then check with cvs stat to see what the sticky tag is, and cvs update -r bname filename if it is wrong. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: how to really remove the information of the file?
When you remove a file from the repository you actually mark it as dead, and it stays in the repository.. Therefore the upcount in revision numbers. Yes. CVS has no way to distinguish between two different files with the same names and the same location in the directory structure. I think the way to permanently delete a file is to to it hard and without using cvs-commands (in Unix use rm) That is if you are clear with that the file and all previous revisions will forever be gone. You also have to have access to removing files from the cvsroot. Right. If you go to the repository and delete the file there corresponding to the offending file but having ,v appended to the end, it's gone forever. This is something to be very careful of. By doing that, you break the repository for any time before the file was marked dead or removed, and you lose that file permanently. This is normally exactly what you don't want in a version control system. And what you get by this is a different revision number. This doesn't matter. You cannot map revision numbers to much of anything else successfully without putting in a lot of pointless work, and so you are almost always much better off treating the revision numbers as magic cookies. When you want to have a coherent setup of the file system that you can refer to later, use tags. That's what they're there for. Revision numbers are for CVS. Tags are for humans. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
tools for deleting the expanded $Log$ comments
Hello members, I would like to know if there is a tools (in perl for example) that delete all the $Log$ expanded comments. Sometimes it is usefull because your classes have revisions for a given project, but if you decide to eliminate from all your code the inserted log comments for a given new revision, or because your are using your class on another project. Do you have any suggestion about how to handle such situation. For example I would like to replace the expanded comments by $Log$, becase I wanto to use such source files on another project. Thanks in advance, David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: tools for deleting the expanded $Log$ comments
Zieg,
Thanks for your code, I have tested we the example file I am sending to you,
but it prints me the followin message: No RCS-formatted logs were found! I
don't know why because I have such logs comments.
I have tested it under:
This is perl, v5.6.1 built for MSWin32-x86-multi-thread
(with 1 registered patch, see perl -V for more detail)
Copyright 1987-2001, Larry Wall
Binary build 631 provided by ActiveState Tool Corp.
http://www.ActiveState.com
Built 17:16:22 Jan 2 2002
Thanks in advance for any help,
David
-Mensaje original-
De: Zieg, Mark [mailto:[EMAIL PROTECTED]
Enviado el: miércoles, 06 de agosto de 2003 15:08
Para: David; Info-Cvs
Asunto: RE: tools for deleting the expanded $Log$ comments
I would like to know if there is a tools (in perl for example)
that delete all the $Log$ expanded comments. Sometimes it is
useful because your classes have revisions for a given project,
but if you decide to eliminate from all your code the inserted
log comments for a given new revision, or because your are using
your class on another project.
Yuck...but I've been there. It's an ugly situation, but sometimes
management comes up with pretty ugly mandates.
You may need to tweak this to work on your coding/comment conventions, but
it worked on a bit of C code I ran it against:
#!/usr/bin/perl -w
#
#
# StripRcsLog.pl
#
#
#
#
#
# Description:Attempts to strip RCS/CVS-inserted $Log$ comments from
a #
# text file.
#
#
#
# Author: Mark Zieg [EMAIL PROTECTED]
#
#
#
# Usage: StripRcsLog.pl commented.c stripped.c
#
#
#
# WARNING:THIS IS DANGEROUS. The algorithm is not foolproof.
#
# Manual verification of cleaned code is highly
recommended! #
# (Of course, you'd only be using this script if you kept
#
# all your code under revision-control...:-)
#
#
#
MAIN:
{
my $State = BEFORE_LOG;
my $Prefix;
while( my $Line = STDIN )
{
if( $State eq BEFORE_LOG )
{
if( $Line =~ /^(.*)\$Log.*\$/ )
{
$State = IN_LOG;
$Prefix = $1;
$Prefix =~ s/\*/\\*/g; # If you understand the need for
this,
} # you get your Perl badge for the
day!
else
{
print $Line;
}
}
elsif( $State eq IN_LOG )
{
if( $Line =~ /^$Prefix/ )
{
# looks like a follow-on log line;
# do nothing, and thus delete line
}
else
{
# looks like the prefix has changed, so
# assUme we've ended the log section
print $Line;
$State = AFTER_LOG;
}
}
elsif( $State eq AFTER_LOG )
{
print $Line;
}
else
{
die( Invalid state: $State\n );
}
}
if( $State eq BEFORE_LOG )
{
warn( No RCS-formatted logs were found! );
}
elsif( $State eq IN_LOG )
{
warn( The log parser consumed the entire file! Probable script
error! );
}
}
DynamicInstance.java
Description: Binary data
___
Info-cvs mailing list
[EMAIL PROTECTED]
http://mail.gnu.org/mailman/listinfo/info-cvs
how to really remove the information of the file?
Dear members, When I remove a file from the repository, the file doesn't exist any more, but, If I want to add a file with the same name, the revision number is not 1.1, it takes in to account that this file was previously removed, so the revsion number is 1.2. Is there any way to avoid this behavour? Thanks in advance, David David Leal Valmaña Tel 91 210 33 00 ext. 71 923 Fax 91 597 05 62 e-mail [EMAIL PROTECTED] Soluziona, Grupo Unión Fenosa Calle Pedro Texeira 8 2da Planta. Madrid 28020 ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: revision macro
I think for your purpose the keyword $Author$ (it is the login name of the user who checked in the revision), the author name or creator, you can introduce by hand on the creation of the file. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]En nombre de KKEnviado el: miércoles, 06 de agosto de 2003 11:24Para: Erik Andersson; [EMAIL PROTECTED]Asunto: Re: revision macro Is it possible to add our own macro to the existing.Say for ex.my requirement is, file should contain the name of the person who modified it recently(this person may be different from the one who created the file) along with the file creator. Thank You very much Regards Krishna - Original Message - From: Erik Andersson To: KK ; [EMAIL PROTECTED] Sent: Wednesday, August 06, 2003 1:59 PM Subject: RE: revision macro Hi! Maybe this is what you are looking for? http://www.durak.org/cvswebsites/doc/cvs_99.php Regards / Erik Andersson -Original Message-From: KK [mailto:[EMAIL PROTECTED]Sent: den 6 augusti 2003 09:13To: [EMAIL PROTECTED]Subject: revision macro Hi all how to and where to set a macro so that the revision of the file appears inside the file. where can I get this information? Thanks in advance Regards Krishna ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Suggestion about how works $Log$ expansion
Dear members, I would like to suggest (I don't know if this is the place to suggest something), that on cvs can be configutated the way $Log$ expansion is produced. Now it just append the last comments in the file, but sometimes it is usefull to delete the inserted comments and to insert all the log information on the files. For example if you have modified your log comment on the file using admin command, such change is not updated into the file, because the keyword expansion mechanism just add new comments. With my suggestion, if the $Log$ expands all it cumulative contents each time, you have such information updated. Another reason is that some code generation could delete the log expanded comments, and just put the token: $Log$, so if you want to update on the cvs the generated code, you get on the expended comment just the last change, because the previous changed were deleted by the generator. Thanks in advance, David ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Update without merge.
Hello, I would like to be able to update my project without CVS merging anything. It should replace unedited files with newer ones if they exist. But files which have been edited (by me but not checked in) should be left alone. I often need to hack up a bunch of files in order to run some test. It would be nice to not have to make all these changes again every time I do an update. Is this possible? Thanks. I'm not really understanding here. Why would you want to do that? If you've hacked up file 1, and another developer changes file 1 and file 2, if you only update file 2 you might well have inconsistent versions that won't even compile. On the other hand, if you update file 1 also, CVS will do its best to merge the repository changes with your hacks. Either it will succeed, in which case you want those changes, or it will find conflicts, in which case you really do need to pay attention to what's changed in the repository. In any case, it looks ot me that the right answer is exactly what CVS does: update all files, and merge changes as best it can. If CVS finds conflicts on the merge, then you need to look at the changes yourself. CVS does not simply overwrite source files; look at the files in the directory with names beginning with .#. You can always therefore get the old versions back, either to overwrite the merged versions or just for reference. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
checkout/commit onto/from shared disks.
Hi, I'd like to start by thanking everyone for the advice I've received from previous posts...so thank you all. Alas, I once more seek your advice though. I intend to build a clustered linux solution for our developers to use. This would comprise of one central server upon which all the developers home directories and cvs server would reside. They will be logged into any one of many machines (nodes). My concern is being that each of our developers home directories will be a disk share from the central machine, and all the checkout/commit will be done via pserver onto these shares (I am considering using NFS to create the shares). If anyone can give me any guidance or foresight of any pit falls with such a mechanism, it would be gratefully appreciated. Thanks Dave B. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
RE: checkout/commit onto/from shared disks.
My concerns were merely that I had heard noises about using CVS on disk shares and was worried (in some part) about corruption, though I could not foresee it. All the clustered machines will be on a Gigabit backbone, so this should negate the network throughput issue. Cheers -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: 17 June 2003 13:10 To: David Bowring Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] Subject: Re: checkout/commit onto/from shared disks. what is your concern? The only one that I can see would be large files with frequent changes over a slow network. But even that wouldnt seem like much of an issue. Tom |-+- | | David Bowring | | | [EMAIL PROTECTED] | | | Sent by: | | | info-cvs-bounces+thomas.maciejewski=us.socgen.| | | [EMAIL PROTECTED] | | | | | | | | | 06/17/2003 08:03 AM | | | | |-+- --- ---| | | | To: [EMAIL PROTECTED] | | cc: | | Subject: checkout/commit onto/from shared disks. | --- ---| Hi, I'd like to start by thanking everyone for the advice I've received from previous posts...so thank you all. Alas, I once more seek your advice though. I intend to build a clustered linux solution for our developers to use. This would comprise of one central server upon which all the developers home directories and cvs server would reside. They will be logged into any one of many machines (nodes). My concern is being that each of our developers home directories will be a disk share from the central machine, and all the checkout/commit will be done via pserver onto these shares (I am considering using NFS to create the shares). If anyone can give me any guidance or foresight of any pit falls with such a mechanism, it would be gratefully appreciated. Thanks Dave B. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs ** The information contained herein is confidential and is intended solely for the addresse(s). It shall not be construed as a recommendation to buy or sell any security. Any unauthorized access, use, reproduction, disclosure or dissemination is prohibited. Neither SOCIETE GENERALE nor any of its subsidiaries or affiliates shall assume any legal liability or responsibility for any incorrect, misleading or altered information contained herein. ** ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
cvs windows 2000 case sensitivity issue
Our cvs pserver is on Solaris. A cvs client is on windows 2000. We are using the latest version for both server and client. Initially, we had a directory in all uppercase (SOMEDIRECTORY). We did cvs remove -f of all the files in that directory followed by cvs commit. Then we made a different directory (SomeDirectory), copied files into that directory, then did cvs add SomeDirectory, cvs add of the files inside that directory, followed by cvs commit. Unfortunately on the windows client, we now get SOMEDIRECTORY filled with files when doing cvs checkout of the module containing SOMEDIRECTORY. The .cvsrc file on the client contains: cvs -q -z3 tag -c update -P -d checkout -P For historical reasons, we would like to keep both directory names (SOMEDIRECTORY for previous releases, SomeDirectory for current and future releases). This seems to be possible on a Unix client, but is it possible in a windows client, where we don't need to have the two directories existing simultaneously? Thanks, Dave. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: cvs windows 2000 case sensitivity issue
On Tue, Mar 25, 2003 at 10:21:55AM MST, Brian G. Peterson wrote: If your Windows 2000 client is using FAT or FAT32 as the filesystem, then no, because the internal representation of the filename is case insensitive, and stored as all upper. If the filesystem is NTFS, it should work. The windows client is on NTFS (just re-verified to be sure), but I am still having the problem. I do a lot of cross-platform development, and Unix development using Windows clients. It try to use all lower for directory names especially, as this type of issue crops up regularly. It seems to be less of a problem with filenames. I agree with this policy recommendation. - Brian Our cvs pserver is on Solaris. A cvs client is on windows 2000. We are using the latest version for both server and client. Initially, we had a directory in all uppercase (SOMEDIRECTORY). We did cvs remove -f of all the files in that directory followed by cvs commit. Then we made a different directory (SomeDirectory), copied files into that directory, then did cvs add SomeDirectory, cvs add of the files inside that directory, followed by cvs commit. Unfortunately on the windows client, we now get SOMEDIRECTORY filled with files when doing cvs checkout of the module containing SOMEDIRECTORY. The .cvsrc file on the client contains: cvs -q -z3 tag -c update -P -d checkout -P For historical reasons, we would like to keep both directory names (SOMEDIRECTORY for previous releases, SomeDirectory for current and future releases). This seems to be possible on a Unix client, but is it possible in a windows client, where we don't need to have the two directories existing simultaneously? Thanks, Dave. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs -- [EMAIL PROTECTED] V-Net: 622-3286 Phone: 1-719-535-3286 Pager: 1-800-724-3624 # 140-1311 - We must get back to basics and drive operational excellence. - We must drive profitable sales and accelerate new product introductions. - We must reduce structural costs and deliver a Plan of Reorganization. - We must rebuild the organization based on accountability, teamwork and trust. --Michael Capellas () ascii ribbon campaign - against html mail /\- against proprietary attachments For assistance, see: http://www.expita.com/nomime.html ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS as storage
hi all, i m newbie regarding CVS repository used as storage. we are using CVS with a document management system. for now 5000 files are added to the repository in a months time. but in couple of months this will go upto 10 times the current load. will this affect access to the repository? will i need some extra tools to manage the repository? This is rather hard to answer. What sort of documents are these? Will they be stored as text, or as binary? Are they exceptionally large? Will the number continue to increase rapidly after 50,000? Also, how many documents will one person normally deal with? During certain operations, CVS builds a copy of everything being checked out or updated in /tmp. If we're talking about 50K documents at 100K each, that's five gigabytes you need in /tmp per simultaneous user, and there are memory requirements also. So, one question is whether the server is big enough. There's also questions of bandwidth if these files are going to be changed frequently, since an update then could result in large amounts of information going around. CVS can handle large repositories, which is about the only answer I can make without knowing more. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
NEWBIE:Question about branching.
Hi, I am fairly new to CVS, I've been using it in a basic form for a few weeks now, that's about it. Here is my problem: I have software which is used for a number of different countries, they are very similar maybe a few different features and functions for each country. For example: I will have software for UK, Europe and Australia. The European and Australian software will be based on the latest UK code with a few additions to some files. ---CVSROOT---| UKSoft_1.0 |---| UKSoft_1.1 |---| | * | * (MERGE FROM UK) ---| AUSSoft_1.0 |---| AUSSoft_1.1 |---| | | *(MERGED FROM LATEST UK) ---| EURSoft_1.0 |---| EURSofy_1.1 |---| This is how I see it. The country variations will never be merged with the trunk (UKSoft) but the additions to th UKSoft will always exist in the others. Can anyone give me any advice on creating and managing such a structure and foresite of any pitfalls. Best regards Dave ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: NEWBIE:Question about branching.
Hi, I am fairly new to CVS, I've been using it in a basic form for a few weeks now, that's about it. Here is my problem: I have software which is used for a number of different countries, they are very similar maybe a few different features and functions for each country. For example: I will have software for UK, Europe and Australia. The European and Australian software will be based on the latest UK code with a few additions to some files. ---CVSROOT---| UKSoft_1.0 |---| UKSoft_1.1 |---| | * | * (MERGE FROM UK) ---| AUSSoft_1.0 |---| AUSSoft_1.1 |---| | | *(MERGED FROM LATEST UK) ---| EURSoft_1.0 |---| EURSofy_1.1 |---| This is not the sort of thing CVS handles very well. Every change from the trunk will have to be merged to every branch, and that's easy to overlook. (You can automate it with a commitinfo or loginfo hook, but it's awkward to handle conflicts that way, and you want to make sure you don't slow normal commits down to a crawl.) Branches in CVS are useful for forking development paths off temporarily, such as creating a release branch so you can continue to fix bugs on it or a development branch so you can try building something new. Another thing to consider is that CVS can run into performance problems with permanent branching. In order to the the latest European revision in the above tree, it will start with the latest UK version and remove all changes until it has the original UKSoft_1_1 (can't use periods in a tag name), and then apply all changes until it gets to the latest European revision. At one time, my company was having significant problems with that (coupled with large things under version control that simply didn't belong there, but I never managed to get anything done about that). So, while there are SCM systems that will do what you're talking about (or at least there was one; I do know of Voodoo on the Macintosh), CVS won't. As already suggested, use conditional code or altered directories. In any case, it's good practice to try to consolidate the country changes into a small number of places. Otherwise, developers will keep missing them. -- Now building a CVS reference site at http://www.thornleyware.com [EMAIL PROTECTED] ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
