Re: CVS - Lock File
Quoting Alan Finlay ([EMAIL PROTECTED]): I am in a bashing mood today. You are target, sorry. > Sometimes waiting an hour > or two and working on something else so the updates can be done > sequentially can save the bother of a merge. So, let me give you an example. One big file. Person A works in the top of it and person B works in the bottom of it. Bam! Also, if you have to restructure your work to work on something else, you might very well waste more than just 2 hours of work. This is for every locking problem. > Branches in CVS are too heavyweight to do this and > when using CVS I am tempted to use a private revision control system to > manage my own checkpoints when the CVS branch is being shared by the team. This is true criticism. Bias - I am using Darcs for most of my projects. I am also one of those academic heads who likes functional languages much more than C or Java. -- jlouis
Re: CVS - Lock File
On Wed, May 04, 2005 at 09:12:42AM -0600, Tobias Weingartner wrote: > On Wednesday, May 4, "Alan Finlay" wrote: > > I have done significant work with ClearCase and CVS in a software > > development team environment, and some minor work with other revision > > control tools. Team size for ClearCase was around 20 developers, and with > > CVS around 10 developers. For an open source project like OpenBSD, CVS is > > quite likely the best choice, but for other situations ClearCase has > > advantages. > > *chuckle* Those are small teams. I've worked on projects (both open > and commercial) that had significantly more developers than what you > mention above. Locking has *never* been an issue for development. It > has, however, been an issue for various PHBses that needed some way to > satisfy their hunger for control over the people that actually get the > coding done. I work on a small team, and locking (I won't mention the tool we're using, but let's just say it sucks) just means that people edit changes without checking the file out and then overwrite each other's changes. CVS++ On subversion, I don't have a problem with it, especially now that you can compile it without BSDDB. It does have the abhorrent new apache license though.
Re: CVS - Lock File
On Wednesday, May 4, "Alan Finlay" wrote: > I have done significant work with ClearCase and CVS in a software > development team environment, and some minor work with other revision > control tools. Team size for ClearCase was around 20 developers, and with > CVS around 10 developers. For an open source project like OpenBSD, CVS is > quite likely the best choice, but for other situations ClearCase has > advantages. *chuckle* Those are small teams. I've worked on projects (both open and commercial) that had significantly more developers than what you mention above. Locking has *never* been an issue for development. It has, however, been an issue for various PHBses that needed some way to satisfy their hunger for control over the people that actually get the coding done. --Toby.
Re: CVS - Lock File
Also the branches provide a record of what changes were made for a bugfix or feature with easy access to a list of all the files affected and which versions of those files. Another benefit of lightweight branching is that developers can use a private branch and checkin incomplete work at checkpoints convenient to themselves without worrying that others will be affected by this work in progress. Branches in CVS are too heavyweight to do this and when using CVS I am tempted to use a private revision control system to manage my own checkpoints when the CVS branch is being shared by the team. ClearCase also allows you to make an unreserved checkout (i.e. one which does not lock the file at all, or to checkout a file already locked exclusively by someone else), however by doing this you clearly signal to the team that you are responsible to clean up any consequences (e.g. this is no excuse for a lost update). To get the full benefit of ClearCase you should use dynamic views, the snapshot views are inconvenient since checkouts of minor branches copy every file to a local workspace and are too slow to create. Dynamic views only copy a file from the repository when you checkout the file, the files you have not changed are accessed in a way similar to NFS using the remote repository as the server. You need dynamic views for the flexibility to use ClearCase efficiently since changing views (i.e. altering the viewspec which determines what a view sees) is then efficient. This makes quick branch comparisons and builds which lock out or pull in changes defined in various ways a convenient way to work. The downside for ClearCase is that it is both time and money expensive. In terms of time, it requires a dedicated maintainer or significant training for the whole team since ClearCase is complex to administer, especially if you are using Multisite (for mirror repository synchronization), and/or using dynamic views. Personally I would avoid using cost of the product as the determining factor in a commercial environment - its usually false economy. I wouldn't use ClearCase unless it has a champion in the team since it is complex when used effectively. A team accustomed to locking may find the switch to CVS uncomfortable, but if they have been accustomed to revision control of directories they will be downright annoyed if given a system without it. Alan Finlay - Original Message - From: "Roy Morris" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 03, 2005 4:50 AM Subject: CVS - Lock File Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris
Re: CVS - Lock File
ed if given a system without it. Alan Finlay - Original Message - From: "Roy Morris" <[EMAIL PROTECTED]> To: Sent: Tuesday, May 03, 2005 4:50 AM Subject: CVS - Lock File Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris
Re: CVS - Lock File
Quoting Peter Valchev ([EMAIL PROTECTED]): > > Have you looked at subversion? A colleague of mine is fanatical about it, > > athough we don't use it here. > > You mean the one that has 23 build dependencies, and only compiles on > i386? Hah. That is the primary problem. The second problem is the problems it solves are not that interesting. The minor touchups are atomic commits (a good thing) and faster branching. But currently, that is about it. I would rather have soeen a good refactoring of the CVS code. I can see that it is what I am going to get. -- jlouis
Re: CVS - Lock File
At 9:55 AM -0600 5/3/05, Peter Valchev wrote: > Have you looked at subversion? A colleague of mine is fanatical > about it, although we don't use it here. You mean the one that has 23 build dependencies, and only compiles on i386? Hah. This sounds odd. I use subversion on FreeBSD/i386, FreeBSD/sparc64, and FreeBSD/PPC without too much trouble. The freeBSD port includes a few knobs to turn of the biggest dependencies, so maybe I benefit from using those. This is the dependency tree that I have: subversion-1.1.4 |\__ perl-5.8.6_2 |\__ libiconv-1.9.2_1 |\__ gettext-0.14.1 |\__ gdbm-1.8.3_1 |\__ expat-1.95.8_1 |\__ db42-4.2.52_4 \__ apr-nothr-gdbm-db4-1.0.1_1 Note that I create all my subversion projects as '--type fsfs', so I don't really use the berkleyDB port. But I thought I'd leave it in there even though I don't use it, just in case I need to access some other subversion project which does use it. I'm still getting used to subversion, but so far I like it. It does address some of the problems that Mark mentioned. I don't know how well it would work for a project as large as OpenBSD, but it is now the "production SCM" for samba.org. So, people are beating up on it in the real-world for some large-scale projects. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
Re: CVS - Lock File
At 09:55 AM 5/3/2005 -0600, Peter Valchev wrote: > Have you looked at subversion? A colleague of mine is fanatical about it, > athough we don't use it here. You mean the one that has 23 build dependencies, and only compiles on i386? Hah. Didn't say *I* liked it, just that a colleague of mine preaches it all the time - if it's a solution to the problem at hand, it's worth considering, warts and all. Lee
Re: CVS - Lock File
> Have you looked at subversion? A colleague of mine is fanatical about it, > athough we don't use it here. You mean the one that has 23 build dependencies, and only compiles on i386? Hah.
Re: CVS - Lock File
On Tue, 3 May 2005, Marc Espie wrote: > To expand on my prior message, CVS is missing some useful features, > but locks is definitely NOT one of them. > Have you looked at subversion? A colleague of mine is fanatical about it, athough we don't use it here. I seem to recall that it address some of the problems you have with CVS. Lee Leland V. Lammert[EMAIL PROTECTED] Chief Scientist Omnitec Corporation Network/Internet Consultants www.omnitec.net
Re: CVS - Lock File
espie: > The main feature I'm missing is the ability to manipulate patchsets > as an independent object. I often have several independent changes > spanning several files, and there's nothing in cvs that allows me > to select one change independently from the others, and not forget > any file. Having to go through diff + patch is creepy and error-prone. darcs is very good in this respect. Source trees consist of sets of patches, and there's a nice patch formalism for deciding when patches can be safely applied. darcs send/darcs apply solve the diff/patch mess (when dealing with patches via email). -- Don
Re: CVS - Lock File
To expand on my prior message, CVS is missing some useful features, but locks is definitely NOT one of them. The main feature I'm missing is the ability to manipulate patchsets as an independent object. I often have several independent changes spanning several files, and there's nothing in cvs that allows me to select one change independently from the others, and not forget any file. Having to go through diff + patch is creepy and error-prone. The second main feature I'm missing is the ability to import stuff on any branch, not just the main branch, and to work off-main branch WITHOUT disturbing the main branch. CVS has got an annoying array of bugs and limitations in that area. The third missing feature is the well-known one of not being able to preserve history across renames. The last feature that would be useful is O(1) tagging... Gee, no locking in there...
Re: CVS - Lock File
Roy, The most important issue, IMHO, is that your team communicates enough to do branching and merging. It sounds from the way the developers referred to the "lock file" that you're considering moving up from Visual SourceSafe. Am I correct on this? The mode of development you're working on will dictate how revision control will work. If you're working on anything involving a Microsoft solution, and using Visual Studio .NET, you're really going to have to work on team communication first, because that bastardization of an IDE changes tens of files behind the scenes and doesn't tell you. You're going to have to keep a master set of project files to do builds if you use a SCM solution other than SourceSafe. Working on anything VS.NET related with a tool other than VSS requires extremely competent development managers to handle the builds and the various quirks that you will encounter. If your team actually can communicate and knows how to use diff utilities, CVS will be fine. If your team works on Oracle, C/C++ outside of .NET, Java, or IDEs that don't hide all the project details, CVS will work really well. If you're in an Oracle and/or UNIX shop, it should fit right in with how those environments expect things to be done. Thank you, Mitch -Original Message- From: Roy Morris [mailto:[EMAIL PROTECTED] Sent: Mon 5/2/2005 2:50 PM To: misc@openbsd.org Cc: Subject:CVS - Lock File Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris CONFIDENTIALITY NOTICE: This electronic message is intended to be viewed only by the individual or entity to whom it is addressed. It may contain information that is privileged, confidential and exempt from disclosure under applicable law. Any dissemination, distribution or copying of this communication is strictly prohibited without our prior permission. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering the message to the intended recipient, or if you have received this communication in error, please notify us immediately by return e-mail and delete the original message and any copies of it from your computer system.
Re: CVS - Lock File
On Mon, May 02, 2005 at 09:10:00PM +0200, Marc Espie wrote: > If you start running into conflicts, it usually means people don't commit > often enough... and if they don't, it might be because intermediate code > is not stable/does not compile, which bodes real bad for the project as > a whole... Or (to second your Java/eclipse rant on ports@) you've a bunch of clueless people not only denying communication but even using braindead eclipse features as "Override and Commit". [I could shoot the guy who added this thing to eclipse] Clear signs of urge of unemployment: - Using graphical tools as in eclipse for CVS access (especially that override-shit). - Commits without reasonable log messages. - Commits that contain two lines with semantical changes but that change the complete file due to reformatting. - Muttering as "that's *my* code" or "I can't work on code formatted like this, so I reformat." Sorry for being offtopic, but out there in the wildness of enterprise/bullshitbingo/java/buzzword world, shit doesn't just happen, but actually accumulates to infinite stupidity. Ciao, Kili, only clueless once a month
Re: CVS - Lock File
Roy Morris wrote: Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris Hi Roy, Not that I know a lots about it, but looks to me looking from the outside that having locking on CVS would mean, only one would work on something and then reduce the collaborations between developers as well as slowing the developments and ideas are not share between multiple heads! (:> Or to be a bit more crud, in business, may mean that if I make something bad, looking my section, mean other can't see my mistakes, so that I am never force to improve them, or correct them and this way,, I keep protecting my job and no talents, or lack of will not show up to often this way! (:> May be I am all wrong, but locking would go in the oppose directions as to communicate and good design that comes from share ideas or process between multiple people where the best idea prevail oppose to mine because I lock the section of code. Plus, improvement couldn't be done by others as it is lock! My $0.02 worth from someone that most likely have no clue of what he is talking about, but only look at the logic of the process and the benefit of learning from others! Or if I think I am God on earth and that I hold the truth, then yes I guess, may be, locking would be something I want as to not have anyone playing in my code! (:> But hey may be many thinks they are God and want locking in their tree! (:> Just an outside point of view. Daniel
Re: CVS - Lock File
Lock files don't replace good communication. There are very little conflict issues in OpenBSD, considering the developers cover the world, litterally. A small projet where developers can talk to each other, live, shouldn't have any problems, even without locks. If you start running into conflicts, it usually means people don't commit often enough... and if they don't, it might be because intermediate code is not stable/does not compile, which bodes real bad for the project as a whole...
Re: CVS - Lock File
* Roy Morris <[EMAIL PROTECTED]> [050502 14:59]: > Our company has started to look at CVS as an alternative to our current > products. When I suggested using CVS I was told not having a lock file > or method of knowing who was working on some code was going to be > unmanageable. (and nearly beaten to death, by the developers) > > Since Openbsd has the OpenCVS project, I thought you all might be > the best people to ask about this. Is this really going to be an issue > for a handful of developers? > > Thanks in advance for your comments. > > > Roy Morris > CVS implements revision control. Communication is left as exercise for the users. Just my opinion. Jim
Re: CVS - Lock File
The entire idea behind CVS is to *not lock*. The entire idea is that people write their own changes, then collaborate on integration, out of band. There is no locking, and there never will be. Locking is used as an excuse by people who don't know how to communicate. > Our company has started to look at CVS as an alternative to our current > products. When I suggested using CVS I was told not having a lock file > or method of knowing who was working on some code was going to be > unmanageable. (and nearly beaten to death, by the developers) > > Since Openbsd has the OpenCVS project, I thought you all might be > the best people to ask about this. Is this really going to be an issue > for a handful of developers? > > Thanks in advance for your comments. > > > Roy Morris
CVS - Lock File
Our company has started to look at CVS as an alternative to our current products. When I suggested using CVS I was told not having a lock file or method of knowing who was working on some code was going to be unmanageable. (and nearly beaten to death, by the developers) Since Openbsd has the OpenCVS project, I thought you all might be the best people to ask about this. Is this really going to be an issue for a handful of developers? Thanks in advance for your comments. Roy Morris
