Re: cvs vs. perforce
On Fri, Mar 29, 2002 at 08:05:06PM +, Bill Northlich wrote: Anyone care to offer reasons, other than free, to use cvs over perforce? Or, the other way around? We are trying to make a decision. The below is based on a theoretical analysis of Perforce and talking to a number of people that use it. This is because I'm working on my own version control system, and have not wanted to get tied up in any sort of license problem with Perforce. Things CVS are better at than Perforce: - Freer license (at least for most purposes) - Easy source availability - Allows mirroring of repositories, so people can work offline easily - Branches with large amounts of small changes (touching many files with small changes) will consume more diskspace under p4 than CVS, due to the - cvs annotate - no similar feature exists in p4 - Better known to open source developers, so you get that kind of support easier Things Perforce are better at than CVS: - Maintaining metadata. Perforce handles more kinds of metadata than CVS; for instance, a commit is a single unit, and is not spread across different files. I also believes it actually handles directories, instead of regarding them as a sort of nuisance and delegating them to second class citizen status. - Speed. Should be much faster. - Ability to do evaluations for all your workspaces, because the metadata is stored on the server - Better branch handling - branches are cheap to create, fast to use, and p4 maintain merge metadata for them, so keeping branches in sync is easier. - Support for rename. All in all, my personal impression is that Perforce is a much better version control system than CVS unless you need the (few) features CVS are better at. Annotate and replication are the most important ones; diskspace is cheap, and in most cases, you'll have enough pain with CVS that you do not want to fix it. Some of the branch issues in CVS can be worked around with careful use of tags (and if you are willing to write code, http://people.freebsd.org/~eivind/CVSFile-0.2.tar.gz can be used to work around more of it), but both of these approaches make replication quite a bit more expensive, which is likely to be a problem if you have a large repository. Eivind. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: using head revision in branch after add on branch
On Fri, Feb 01, 2002 at 02:16:20PM +0100, C. Wienberg wrote: If we kill the ,v-File from the repository, andd add the file on the head branch, we will loose the file's history. Is there any better way? All we want is to get the symbolic name branchname point to the same version as head! The following will probably work, but is DIRTY, and I am not certain what side effects it may have on other apps trying to interact with the CVS repository: cvs admin -Nbranchname:1 filename I recommend taking a backup of the CVS repository before doing this. Eivind. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: pwd_mkdb for Linux?
On Wed, Jan 30, 2002 at 11:37:11AM -0600, Neil Aggarwal wrote: Hello: I am trying to follow the instructions for setting up a CVS tunnel over SSH contained in this doc: http://www.prima.eu.org/tobez/cvs-howto.html At one point, it asks me to run pwd_mkdb -d . master.passwd But, I can't find pwd_mkdb on my Linux system. These are FreeBSD instructions; I can see that both from the command requested (pwd_mkdb) and the URL (tobez is one of the FreeBSD developers). You should probably be able to just drop that step; Linux use (d to use?) /etc/shadow instead of /etc/master.passwd, and did not use database files (which FreeBSD use for acceleration, but which also makes the password handling more complex.) Eivind. ___ Info-cvs mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/info-cvs
Re: CVS and FreeBSD
On Wed, Aug 30, 2000 at 04:33:20PM -, Peter Disiot wrote: Hi all I am running freeBSD 3.2 STABLE and I am wondering which version(s) of CVS I can download from the web to upgrade to. As freeBSD is yet to be added to the OS list on the www.cvshome.org web page could someone please tell me which one(s) I can use. I have a feeling the unix OS will work, but someone please confirm. Secondly what are the catches to upgrading. Never done the upgrade thing before so any info would be appreciated. Just upgrade FreeBSD itself - CVS is bundled, so you get new versions of it 'for free', and it probably won't be much more work than upgrading just CVS. It also gives you the benefit of having a system that is more in sync with the world as it is today. Normally, I do not recommend upgrading anything more than you have to - never upgrade without a reason. However, 3.2-STABLE is old enough that an upgrade probably is in order just to sync with the world. And to answer your original question: FreeBSD would be Unix in that sort of questionaire. Eivind.
Re: cvs-nserver and latest CVS advisory
On Thu, Aug 10, 2000 at 05:45:09PM -0400, Noel L Yap wrote: [EMAIL PROTECTED] on 2000.08.10 16:41:35 Yes. Because either they are doing something nasty or someone has compromised their password. I do use real unix uids so I can determine which *userid* did the damage, providing they don't break root (in which case no authentication system can hope to help you, unless you have extensive off-site logging, etc.) But the real culprit gets away. This wouldn't happen with SSH. This assumes that you do not have ssh authentication theft (as discussed in a previous message.) I have seen ssh auth theft involved in about 20% of the security violations I've seen in the last 3 years. YMMV, of course. Eivind.
SSH security (was Re: cvs-nserver and latest CVS advisory)
On Wed, Aug 09, 2000 at 10:53:10AM -0400, Greg A. Woods wrote: (Mind you -- I cannot say the above without also stressing the risks of something like SSH are not zero -- the server must still trust the physical hardware and the operating system within the client since SSH can easily be used covertly by a virus or worm! This means that SSH users on both ends of the connection must continually secure their systems and provide reasonable assurances against such covert use!) If you use ssh-agent or X11 forwarding: Not just the client - all the machines that gets logged in to using that key (with forwarding). Oh, and if you want to use agent forwarding at all, you have to either use it everywhere or remember to disable it each time you connect somewhere it shouldn't be enabled - there is no enable switch (in the official version(s) - a lot of us patch it locally.) And there is no logging of what authentication your agent does. I *highly* recommend not using world-accessable authorized_keys files; restrict them by IP address. It at least gives you some security from compromised hosts, and will even make ssh more secure than .rhosts, overall. X11 forwarding is still a large risk, of course. Eivind, who becomes less and less of an ssh fan the more he thinks about ssh.
Re: SSH security (was Re: cvs-nserver and latest CVS advisory)
On Thu, Aug 10, 2000 at 12:15:09PM -0400, Noel L Yap wrote: [EMAIL PROTECTED] on 2000.08.10 08:43:36 I *highly* recommend not using world-accessable authorized_keys files; restrict them by IP address. I've been wondering, how does this restriction work? Does the client send over its IP address to the server? If so, can't someone patch the client to send over a different IP address? It just make the server check the source IP address of the socket the authentication is coming in over (ie, your ssh connection.) Similar to a .rhosts file, sort of. If I have a restriction in my authorized_keys file saying e.g. from="222.111.0.99,192.168.1.1" 1024 33 public key data then I will only be able to use ssh's RSA-based challenge authentication (the one ssh-agent use, usually based on ~/.ssh/identity) directly from the machines with the IP adresses 222.111.0.99 and 192.168.1.1 (both of which are made up.) Eivind.
Re: .trunk patch refinement
On Mon, Jun 19, 2000 at 05:13:10PM -0500, David Thornley wrote: Mike Little referred to "some previous cvs admin", and this is precisely what happened in my case. Some previous CVS admin put some of the rev numbers to 2.x, and there's no way I can put them back to 1.x. You could probably do this using CVSFile (http://people.freebsd.org/~eivind/CVSFile-0.2.tar.gz) and a small perl script. This would, of course, invalidate any workspaces (checked out copies of the source) presently active. Note that I have not tested CVSFile with repositories that contain 2.x versions, and there may be bugs in CVSFile related to using such repositories - though as long as you don't directly overwrite your original repository, there should be no chance of data corruption. CVSFile lacks documentation - sorry about that. Eivind.
Re: distributed repositories
On Tue, Jun 13, 2000 at 03:03:04PM -0700, Thomas Olausson wrote: Is it possible and/or has anyone set up CVS with two different repositories, allowing distributed development, and then having an admin or a script merging them together periodically. I'd like the two different groups to be able to develop on their own, but not having to touch the other group's repository, at least not individually. I have made a perl module for manipulating CVS files that is intended for use with this (and to allow import of CVS files with history into other version control systems.) I have not made any example of how to make an import from another repository (or much else - what is there is really just code to verify that the module works correctly.) The module has been tested by reading and writing out the entire FreeBSD CVS repository and diffing the results. The only differences I found were due to old, non-normalized files in the FreeBSD repository (whitespace diffs) and bugs in the repo (dual tags - it seems that CVS at one time allowed import with the same branch-tag and tag, and the module collapses this to one tag.) Caveats: The module does NOT do CVS locking yet, and there is no documentation, and I do not presently have time to write any. I'll trade you the URL for documentation. Here goes: http://people.freebsd.org/~eivind/CVSFile-0.2.tar.gz - now you have to write documentation ;-) Feel free to bother me about any bugs, or quick questions as to use - but do not expect me to do a tutorial, as I presently do not have time. Eivind.
