Re: --> How to delete a Branch ???
Alex Carlos wrote: Hello, I´m new on CVS, and I have to clean up our server. People starter a lot of "test branches", to test the software, and now I want do delete then. But I already read on documentation that this operations is not suported,but possible to be made from tag and rtag commands... Sometimes "not supported" really means exactly that. You can force delete the branch tag *BUT DON'T DO THAT*. If you do, any revisions on the branch still persist, but only accessible by revision numbers - and there is no way to refer to the branch as a whole across all files - the remaining numbers may be unique to every file. Effectively what you end up with is lots and lots of unnamed branches - a seperate one for every branch for every file that was touched in that branch. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: CVS to Subversion
Mario Scheer wrote: Hi, I have some troubles converting a CVS repository to a Subversion repository. I'm using the tool cvs2svn.py. (http://cvs2svn.tigris.org) I always get this error message: Unable to convert a path 'trunk/defaullt/rve/ap/tact/comp/data_reiseb¦ro.zip' to internal encoding. Consider rerunning with (for example) '--encoding=latin1' I know that there is a "¦" in the filename, because it's a german symbol. I tried cp850, and UTF-8 as encodings, but it doesnt work. Any ideas? Why not try asking on the cvs2svn users mailing list? Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
MD5sums in release announcements (was Re: Stable CVS Version 1.11.17 Released! (security update))
Derek Robert Price wrote: > I am no longer including MD5 sums in the release announcements since I > am now posting a detached GPG signature file with the downloads. Let's hope it never happens again, but, during the recent cvshome.org outage, the md5sums in the release announcements were *extremely* useful. The release announcement emails had been independently archived by several different mail archives, thereby providing a reliable source of the true md5sum. When people began to put up their downloaded cvs tarballs on various sites, this md5sum was extremely valuable in verifying that these second-hand tarballs were truly the real release. If it doesn't create too much work for you, perhaps you could reconsider this decision? Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/info-cvs
Re: Regarding how deltas are stored in CVS
Doug Lee wrote: > It was mentioned on another thread that CVS stores the HEAD revision > in its entirety, older trunk revisions as backward deltas from the > HEAD, and branches as forward deltas from the branch point. > > If I read this right, a common case will take a lot more space than I > thought. My current project is an example: I was just asked to go > back and apply some current features to an old revision of a set of > files. When I did that, I put in as much of the current code as I > could without allowing any code to go in that could have side effects > outside those intended. Some files I could literally copy from the > HEAD revision (though I did it via the appropriate merge commands); > others came close but not quite there, and of course still others > remain very different from the head of the trunk. > > But I think what people are saying is that a copy of the head of > the trunk, when placed on a branch, will basically create a > reverse-duplicate set of deltas (perhaps condensed into a smaller > number of them of course) to the set between the head of the trunk > and the branch point. Correct. > Somehow I'd been assuming that CVS would > maybe notice that the head of my branch and the head of the trunk > produced identical contents for some files and might only store one > copy. > > I don't yet know enough about the RCS file format, but I wonder if the > format itself would support deltas forming a different graph than is > currently formed, to optimize file size and/or number of deltas from > point to point. No, not without changing it so much it would essentially be an entirely new and different format. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Moving a CVSNT Repository to Linux.
Carter Thompson wrote: > Hi All, > > I'm going to help a friend move his CVSNT repository from Windows 2000 > to Linux. Knowing that we'd like to preserve the history and copy > all the RCS files to the new machine what problems can I expect, If you have been using usernames containing spaces, that will be a problem. CVS doesn't support them, they are a CVSNT extension. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: SSHD user-switching under Cygwin/XP (was Re: Case insensitivity ad nauseum)
Derek Robert Price wrote: > My research so far leads me to believe that the problem is that the > Local System Account does not have permission to access the drive. ... >>> 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). I haven't been following the case-insensitivity thread, but is this the problem: You are logging in to Cygwin sshd using publickey auth (i.e. no password), and you cannot access a Samba/Windows share that your user should be able to? If so, the explanation is this: sshd runs as the Windows SYSTEM user (or other user with sufficient rights) to create Windows authentication tokens. These are fully valid on the local machine, *but* if you do not log in with a password, the token does not contain a password (because there is no way to know what it is - it is hashed in the Windows password database). Therefore, no password = unable to authenticate to remote machines, therefore unable to access network shares. There is no elegant solution. Inelegant solutions include: * Only log into sshd with a password. * Put your password into a file only readable by you, and use it with the Windows "net use" command during your .profile, to connect to the network share. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and gdbm?
[EMAIL PROTECTED] wrote: > On 5 Sep, Max Bowsher wrote: >> > Is there any further info on configuring CVS to use gdbm? Especially, >> > benchmarks? >> >> No benchmarks, but the "appropriate edits" to use gdbm exist in the Cygwin >> package of cvs. > > Interesting. That would explain the recent Cygwin announcement of the > need to use the conversion program following the recent changes to gdbm. > > So I take it that there's some benefit seen in using gdbm; presumably > related to performance? But that for some reason it's not considered > the right choice to make it the default for Unix. (Perhaps because > Unix people prefer to use plain text where possible, to leverage from > all those existing plain text utilities.) There are 2 separate issues - text/dbm and ndbm/gdbm. text/dbm: This is supposed to be an optimization option for repositories with truly huge modules and/or val-tags files. I don't know of any benchmarks to quantify the effect. ndbm/gdbm: ndbm (.dir/.pag) is not functional on FAT filesystems, hence not suitable for use on Cygwin. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and gdbm?
[EMAIL PROTECTED] wrote: > The CVS FAQ says: > > By default, the `modules' file behaves as described above. If the > modules file is very large, storing it as a flat text file may make > looking up modules slow (I'm not sure whether this is as much of a > concern now as when CVS first evolved this feature; I haven't seen > benchmarks). Therefore, by making appropriate edits to the CVS source > code one can store the modules file in a database which implements the > ndbm interface, such as Berkeley db or GDBM. If this option is in use, > then the modules database will be stored in the files `modules.db', > `modules.pag', and/or `modules.dir'. > > Is there any further info on configuring CVS to use gdbm? Especially, > benchmarks? No benchmarks, but the "appropriate edits" to use gdbm exist in the Cygwin package of cvs. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: normalizing files and old revisions
Andreas Klauer wrote: > On Sunday 31 August 2003 20:47, Max Bowsher wrote: >> Andreas Klauer wrote: >>> Any hints on how to do this? >> >> Write a script that walks an RCS file, and for each revision, generates the >> fulltext from the stored diffs, pipes the fulltext through your filter, >> diffs it against the previous revision, and writes out the new form. >> Don't forget to use the "next" properties to handle branches correctly. >> >> I.e. - not a trivial task. > > First, thank you for your reply. :-) > > The parsing of the RCS files should be trivial enough, the format does not > look too complicated to me. Of course, I haven't yet read the rcsfile-manpage > thoroughly enough, so I could be mistaken. Yes, the basic parsing shouldn't be too difficult. However, the need to undiff and rediff, whilst respecting branches, is where the complexity arises. > However, I seem to have a problem with the diffs, considering keywords, > especially the $Log$ keyword. All my files contain this keyword, and > naturally, my own diffs contain the automatic changes to this log in every > revision. However, the original diffs don't, or only do, if someone actually > modified the log directly in the file. I'm pretty sure that my diffs will > mess up things if they contain log changes. I don't think there is a problem here. You read each revision's text from the RCS file, (applying diffs to get it), then filter as desired, and re-generate the diff against the previous revision. Sure, if your filter changes log text in the file, it will not correspond accurately to the actual log messages. But that's a problem for the filter, not the method in general. Can you explain the problem you percieve in more detail? > So, my (hopefully not too stupid) question is: > How can I create diffs exactly the same way CVS does, without considering the > $Log$ and other keyword's stuff? Take a look at some RCS files. CVS doesn't actually contract keywords on checkin. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: normalizing files and old revisions
Andreas Klauer wrote: > Hello, > > in order to get rid of whitespace problems (tabs<->spaces, trailing spaces, > CRLF(\r\n)<->LF(\n) linefeeds) I want to add a filter to CVSROOT/commitinfo, > which normalizes (modifies) the corresponding files before they are commited. > Can anyone confirm that this is the way to go? I got this solution from the > cvsIndent project, which reformats whole files when commited. Is there a > better one? > > Now, to my main problem: > The repository already contains files which use tabs, CRLF, et cetera. > Corresponding diffs to old revisions already contain loads of unnecessary > whitespace changes. I'd like to get rid of these diffs, to make comparisons > between never revisions (which use filter) and older revisions (which didn't > have the filter) possible without getting all this whitespace changes junk. > > Is it possible somehow to rebuild the repository, to apply this normalizer to > old revisions, without influencing commit dates, authors, log entrys, > statistics, so that the resulting repository looks like as if the normalizer > script was used from the very beginning? I want to make this change > completely silently. > > I suppose that this is not quite in the CVS spirit, because this way old > revisions can't be restored the way they really were. However, I have backups > of the repository so that isn't a problem, and it's highly unlikely that > whitespace changes will affect anything anyway. I'd really prefer to have > clean diffs. And I can't use diff's 'ignore whitespace'-option, because the > normalizer script probably will do other things too (like conversion of > charsets, german umlauts, ...) > > Any hints on how to do this? Write a script that walks an RCS file, and for each revision, generates the fulltext from the stored diffs, pipes the fulltext through your filter, diffs it against the previous revision, and writes out the new form. Don't forget to use the "next" properties to handle branches correctly. I.e. - not a trivial task. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Adding files on branch off a branch
Matthew Herrmann wrote: > Hi All, > > If I create a new file on a branch of a branch, it creates a 3-digit > branch (ie 1.1.2), and not 5 digit ones like all the other files which > were already on the first branch and were then subsequently modified. > > I think this is because the simple handling of newly created files just > adds a deleted revision 1.1 and then resurrects it on the branch. > > My question is, when I then merge back onto my first-level branch, it will > try to resurrect the 1.1 file from the trunk, won't it? But that revision > number will already have been taken by the branch of the branch. So either > it will have to give it an unrelated number, which breaks the idea that > 1.1.2.4.5.6 is always a descendent of 1.1.2.4, or it will clash on the > revision number of the existing branch and crash. The new revision on the first level branch will be 1.1.4.1 Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Info-cvs Digest, Vol 8, Issue 6
> -Original Message- > From: Larry Jones [mailto:[EMAIL PROTECTED] ... > Why? It's "cvs rtag" when used without the -r option that's truely > dangerous, since you have no way of knowing what revisions you're > tagging. Matthew Herrmann wrote: > I always understood that "cvs rtag" without a "-r" would tag the latest > version of all files on the trunk, synonymous with "cvs rtag -rHEAD tagname > module" (?) I had been using it in this manner for some time and not > experienced behaviour to contradict this. Yes, but what if someone commits something between when you decide to run the rtag and when you actually run it? That is the danger. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Need advice about revision management
Frank Langtind wrote: > Hi, > > Our company is in the process of changing from RCS to CVS for revision > control and I'll need some advice to make it as good as possible. > > Our work in divided in project groups that work with modules and project > groups that work with products. The module projects are arranged like > this: > > > module1/doc/ > src/ > qa/ > > > Our product projects use some of the modules and is arranged like this: > > project1/doc/ > src/ > qa/ > import/module1/ > module2/ > > The import/moduleX directory within the product project contains only the > source from the moduleX (not documentation or qa stuff). > > This is obtained by using the "modules" file and work great. When we > check out the product projects, all required module sources are checked > out like expected. > > Since the modules are maintained independently, they have different > releases. > > Since different products use different releases of the same module (ie. > due to backward compatibility issues) we would like to specify which > releases a product should use. Like: > > Product1 should use module1 REL2_1, module2 REL1_4, module3 REL1_2, etc... > Product2 should use module1 REL2_5, module2 REL1_3, module4 REL2_2, etc... > > I could not find any way of doing this in CVS. Hopefully I have missed > something ;) > > I'm sure there must be other people having the same problem. Anyone care > to suggest ways of doing this, available scripts to help out, or maybe an > alternative methodolgy (after all we are in the process of changing..). AFAIK, the only way to do this is to have a script (possibly part of your build process) which issues "cvs co -r REL_WHATEVER" commands. Then you keep that script in your project directory, and it defines what branch/tag you use with the project. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Delete a branch
Sanjay Bhatia wrote: > Thanks Max and Larry for your replies. > > I am convinced that our server is too old to deal with the -B flag. > > Here's the situation I am trying to fix. I have a testing branch that was > created many changes ago from the dev. branch. I need to sync them up. > I was thinking of deleting the test branch and then re-creating it. Sounds simple, really isn't. One simple possibility is to create a new (differently-named) test branch. > Is there a way to do this with a join instead? Will the join take care of > files that are deleted from the dev. branch but exist in the test branch? Yes, you can join (cvs up -jrev1 -jrev2). I haven't personally worked with joining file deletions, but I think it should. Joining can be troublesome unless you keep certain tags: If B is a branch from A, and joins take place from A to B: Tag the branchpoint. If this was not done at the time, you will need to investigate and reconstruct it by examining cvs logs to find the time of branching, and then using applying a tag by date. If you need to do this, google for "cvs2cl", which will produce a unified log of an entire directory tree. Also, tag the point in A up to which you have merged into B. Since merging may involve manual conflict resolution, use this procedure: 1) Tag (as merging-A-B, or similar) the point you will merge up to (usually the tip of A). 2) Do the merge, commit the resultant changes to B. 3) Tag (as merged-A-B, or similar) the position of the merging-A-B tag. You may choose to not explicitly tag the branchpoint as B-branchpoint or similar, but to just tag it as "merged-A-B" immediately on creation. The point of this is that you then always have a pair of tags to give to the join command. There is a useful set of scripts at http://devel.squid-cache.org/CVS.html which implement this scheme. It is quite complex, but if you can dedicate an hour to figuring out how the scripts work, they are very useful. Whilst I am recommending them, I must mention that the cvsclosebranch script attempts to delete a branch tag without -B - so it won't work on current clients - but I consider this a good thing, since I think deleting the branch tag is an excessively destructive thing to do. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Delete a branch
Sanjay Bhatia wrote: > Hi > > I have a branch that I need to delete. Please explain why you need to delete the branch. Deleting branches is often highly undesirable. > I followed the instructions in the > manual (http://www.cvshome.org/docs/manual/cvs-1.11.6/cvs_4.html#IDX125) > and adding a -B option did not help. I tried 'cvs rtag -B -d branchname > modulename' and I got a message saying that -B is not a valid option. Sounds like your cvs client is too old. NB: cvs rtag -d -B does NOT delete a branch. It only untags it. This is only a good idea if no revisions have *ever* been commited on the branch. If any have, the result of untagging is to leave anonymous branch revisions. By some definitions, this could be called corruption of the repository. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: acl for cvs try II
Edward Peschko wrote: > ok, > > here's acl for cvs - try II, to see if its getting through to the list. > The patch implements very simple acl at the code level, and works against cvs-1.11.5/6. There is a more complex acl patch here: http://home.attbi.com/~minyard/ It might interest you. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: checkout/commit onto/from shared disks.
David Bowring wrote: > 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. AFAIK, the corruption issues relate to storing the repository itself on a network share. Max. > -Original Message- > From: [EMAIL PROTECTED] > > 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]> | >> -+-> > > 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. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Deleting a branch....
You sent this to me privately. Please don't do that - if you had sent it to the list, someone else might have replied by now. Gurpreet Singh (SCM) wrote: > Thanks Max. > Then can we regulate the branch to be created or not... like can we define > priveleges who can create the branch/tag ? > How can we put check on it. There are 3 possibilities: 1) It may be sufficient that anyone who can commit, can branch. If so, a readers or writers file should suffice. 2) Use the hook scripts in CVSROOT to control access. IIRC, there is a cvs_acls included in the distro. 3) Corey Minyard's ACL patch. NB: I have never used any of these myself, so consider this as a pointer to further research. Max. > -Original Message- > From: Max Bowsher [mailto:[EMAIL PROTECTED] > Sent: Friday, June 06, 2003 9:55 PM > To: Gurpreet Singh (SCM); [EMAIL PROTECTED] > Subject: Re: Deleting a branch > > > Gurpreet Singh (SCM) wrote: >> Hi All >> >> This is regarding deleting a branch, thus created on a Module. >> Is there any specific method / decription in doing it so ? >> >> Well I tried to untag it ^ with the following command >> >> cvs rtag -d BranchName ModuleName >> Is this the only way to do so..? >> >> Moreover, All the subfolders were not untagged / say deletion of branch >> completely... ? > > Deleting a branch is not usually a good idea. > > Simply untagging (rtag -d) saves virtually no space in the repository, > because all the revisions remain there, but they are now anonymous and > inaccessible except by revision number on an individual file basis. > > So, basically, don't delete branches. > > > Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: Deleting a branch....
Gurpreet Singh (SCM) wrote: > Hi All > > This is regarding deleting a branch, thus created on a Module. > Is there any specific method / decription in doing it so ? > > Well I tried to untag it ^ with the following command > > cvs rtag -d BranchName ModuleName > Is this the only way to do so..? > > Moreover, All the subfolders were not untagged / say deletion of branch > completely... ? Deleting a branch is not usually a good idea. Simply untagging (rtag -d) saves virtually no space in the repository, because all the revisions remain there, but they are now anonymous and inaccessible except by revision number on an individual file basis. So, basically, don't delete branches. Max. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
