Date: Thu, 2 Feb 95 14:22:12 MST From: terry@cs.weber.edu (Terry Lambert) To: hackers@FreeBSD.org Cc: terry@cs.weber.edu (Terry Lambert) Subject: Source Tree Ettiquite (was Re: sup: Ok, I'm gonna do it.) Message-ID: <9502022122.AA14716@cs.weber.edu> In-Reply-To: <9502021836.AA21648@halloran-eldar.lcs.mit.edu> from "Garrett Wollman" at Feb 2, 95 01:36:49 pm
next in thread | previous in thread | raw e-mail | index | archive | help
Must I pretend to the title of 'Source Tree Emily Post'? OK, for the benefit of everyone, I will play the source tree asshole. Every successful project involving more than one developer needs a source tree asshole. Since it is a full time job, I will only pretend to do the job for the duration of this posting. Other people can step into the shoes as exceptions crop up. Managing by exception rather than by crisis is the way things should be taken care of anyway. Let it be first noted that I generally agree with Garrett's decisions and have faith in his inherent common sense and deep understanding of "the way things ought to be". This is, more than anything else, a trieste on source tree ettiquite in a distributed developement environment, and what I think is *a* right way to do it. Before you rip my lungs out, note that "*a* way" is intentionally not written as "*the* way". If you attack me on this point, I will point at this paragraph and solicity your suggestions; you had better have *a* right way of your own ready. The status quo is currently inadequate. It also results in class distinctions of the type of which Linux users accuse BSD. > > As Terry points out, the same thing can be accomplished by the appropriate > > use of cvs controls. > > I SAID, I DON't HAVE ENOUGH DISK SPACE TO KEEP TWO COMPLETE COPIES OF > THE SOURCES TO EVERYTHING! Neither do I, which is why I suggested the precise process that I did instead of a cascade of multiple snapshots. The multiple snapshot approach (which I will call "the bogus approach") requires extracting a full copy of the source tree and attempting to build it. Meanwhile, the previous successfully built snapshot is still on line. So you have a CVS tree, a snapshot and a snapshot. During the copy phase (assuming the build and the distribution snapshots aren't on the same machine, which makes sense), this is pushed up by yet another snapshot, if only for a short period of time. On the other hand, the locking I proposed is *advisory*. What does that mean for multiple reader/multiple writer locking? It means that you can check in to the tree without acquiring a writer lock. When you break the world, you get a bunch of email calling you a dickhead. It means that you can check out of the tree without acquiring a reader lock. When you do, and your world breaks and you complain, you get a bunch of email calling you an idiot. Long term reader/writer locking means you (the developer) don't even need enough disk space for ONE COMPLETE COPY OF THE SOURCES TO EVERYTHING. With a writer lock, you may check in over NFS, as long as you are timesynced and hold the lock for the duration of the checkin. AMAZINGLY, THIS RESULTS IN A LOT MORE PEOPLE BEING IN A POSITION WHERE THEY CAN CONTRIBUTE TO THE PROJECT, WHAT WITH THEM NOT NEEDING A FULL SOURCE TREE AND ALL. If you conflict with someone else (multiple writers being allowed), you will have to resolve it between you. You two should be coordinating the changes both of you are making to stdio.h anyway, unless you plan on falling prey to the adage that "too many cooks spoil the meal". Meanwhile, since the checkout for the snapshot always acquires a reader lock before doing the checkout, only a dickhead can cause the tree state to be inconsistant. The net effect of this is to simply prevent the snapshot process from being an idiot by accident. For the snapshot to be an idiot requires a dickhead to interact with the tree. And then it isn't snapshots fault. Does this require you to build the world before you can safely let go of a writer lock without being a dickhead? No. It requires that your dependencies in your makefiles *work* so you limit the scope of your rebuild automatically. It requires that you check for conflicts with other writers when checking in before you release your writer lock. People are currently working on getting the depndencies working all the way; we are now very close. This is why the idea should again be considered. What if I change a file that a *lot* of things depend on? I should have to rebuild a lot of things. People should be required to think about changes that impact large amounts of code proportional to the amount of code they are affecting. If this is annoying, you are probably crapping in the tree occasionally because testing your code isn't as exciting as writing it, and so you are pushing that job off onto other people who are supping the crap and notifying you posthumously. Or you are a god. You are probably not a god. "AHA!", You exclaim, "That still leave the CVS tree, the snapshot, and the previous snapshot, so you haven't reduced space requirements at all!". You think you have fooled me. You have not. This usage protocol can just as easily apply to SUP and other snapshot "consumers". They can be locked out during the snapshotting process. "Request deferred/denied. Use the lock override option if you need the code now and are willing to take it in an inconsistant state". Thus we are left with CVS + 1 snapshot, rather than CVS + 2(3) snapshots. Since for releases, the tree is tagged and branched anyway, there are no impacts on release engineering (except an extra 1(2) snapshots worth of disk space to do the engineering in). Do I think this will result in a buildable source tree? Yes, most of the time. There will be drug interactions, where apparently unrelated changes screw with each other. Some of these will even be impossible to prevent using corrections to the broken dependency lists that resulted in the problem. But these will be rare, and they will get rarer as the dependency lists are corrected on a per occurance basis. Does "buildable" mean "runnable"? No. I am not an idiot. "Buildable" means "buildable", nothing more. Going from "buildable" to "runnable" is called release engineering. This posting is about source tree ettiquite. Terry Lambert terry@cs.weber.edu --- Any opinions in this posting are my own and not those of my present or previous employers.
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9502022122.AA14716>