Re: cvsup
2008/1/21, Dave Hayes [EMAIL PROTECTED]: Matthew Dillon [EMAIL PROTECTED] writes: What, people didn't know we install a Makefile in /usr? Well, now you do! Er...maybe it's because I'm running 1.8.2 that I don't see one in /usr? When did you folks start doing this? 1.10 IIRC.
Re: cvsup
Matthew Dillon wrote: One of the original reasons for using cvsup was so people could maintain local branches of the repository. I don't think people do this much anymore, if they do it all. Disk space is so cheap these days that keeping a master sync copy and a separate one for local work is not a big deal. People use git or hg nowadays :) I just can't stop nagging, it is unbelievably useful, especially for team work. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: cvsup
People use git or hg nowadays :) I just can't stop nagging, it is unbelievably useful, especially for team work. It's been now many times I heared great things about git, while I never personally used it, as I use rsync to keep my development projects syncronized. Why don't we switch to to git now? Think we would be the first *BSD OS project to dump CVS and not that it would be a bad thing by the sounds of it :) Petr
Re: rsync and new mirroring tool (was cvsup)
On 2008-01-21, Matthew Dillon [EMAIL PROTECTED] wrote: We could just add rsync targets in our /usr/Makefile in addition to all the cvsup/pkgsrc targets already in there. What, people didn't know we install a Makefile in /usr? Well, now you do! -Matt Also, before you decide anything, I should let you know that I decided to go ahead and write a general purpose rsync based mirroring tool, both for keeping our own dcvs copy updated and for doing convenient rsync vs cvsup benchmark testing. I have been working on it for two nights now. It is written in Perl and, so far is working pretty nice. I call it *mirror*. I have a configuration file for it that is pre-configured for all the DragonFly rsync repository mirroring sites that I know of so far. It is even more convenient than cvsup. I plan to make it available, hopefully in the next day or two. I was going to set it up as a standard installable source package (i.e. make install) and write a manual first. I was considering hosting it as a project on my own site or one of the project hosting sites or see if you guys are interested in putting it up on the DragonFly site. I would be interested in feedback. It has some pretty nice features so far. Just to give you a little preview, I have included just the configuration file below for DragonFly dcvs mirroring. === # mirror-dragonfly-cvs.conf # # Settings are specified as # variable = value # or # variable += value # to append to a variable. # # This mirror file will maintain a copy of the DragonFly BSD CVS tree. # # $Id$ # # $sites # Source URLs or paths for retrieving file updates. # Example: rsync.TheShell.com::DragonFly/dcvs # or: rsync://rsync.TheShell.com/DragonFly/dcvs # sites = rsync.TheShell.com::DragonFly/dcvs sites += rsync.AllBSD.org::dragonfly-cvs sites += chlamydia.fs.ei.tum.de::dragonfly-cvs sites += crater.dragonflybsd.org::dragonfly_cvs # $destination # Specifies where to place the requested files. # destination = /home/dcvs # $rsync_opts # Options to pass to rsync # rsync_opts += --archive --hard-links --delete rsync_opts += --compress rsync_opts += --verbose #rsync_opts += --progress # $files # Files or directories to mirror # files = CVSROOT# Basic CVS data. Required to use cvs. files += src# The DragonFly source code files += doc# Documentation #files += site # The DragonFly website code
Re: cvsup
* Steve O'Hara-Smith wrote: On Mon, 21 Jan 2008 09:24:02 +0100 Nicolas Thery [EMAIL PROTECTED] wrote: 2008/1/21, Dave Hayes [EMAIL PROTECTED]: Matthew Dillon [EMAIL PROTECTED] writes: What, people didn't know we install a Makefile in /usr? Well, now you do! Er...maybe it's because I'm running 1.8.2 that I don't see one in /usr? When did you folks start doing this? 1.10 IIRC. Eh? I thought that was a joke. There's no /usr/Makefile on this box (1.11.0-PREVIEW). Nope, its not :) Look at the cvs log of src/etc/Makefile.usr: revision 1.1 date: 2007-08-02 08:53:14 +0200; author: dillon; state: Exp; commitid: 9C2uflYNvgKK29ss; The distribution installs a Makefile in /usr with easy-to-use targets to create a pkgsrc distribution and to obtain the DragonFly CVS repository and checkout/update /usr/src. A make in /usr with no arguments will list available options. Matthias
Re: cvsup
On Mon, 21 Jan 2008 09:24:02 +0100 Nicolas Thery [EMAIL PROTECTED] wrote: 2008/1/21, Dave Hayes [EMAIL PROTECTED]: Matthew Dillon [EMAIL PROTECTED] writes: What, people didn't know we install a Makefile in /usr? Well, now you do! Er...maybe it's because I'm running 1.8.2 that I don't see one in /usr? When did you folks start doing this? 1.10 IIRC. Eh? I thought that was a joke. There's no /usr/Makefile on this box (1.11.0-PREVIEW). -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Re: cvsup
2008/1/21, Steve O'Hara-Smith [EMAIL PROTECTED]: On Mon, 21 Jan 2008 09:24:02 +0100 Nicolas Thery [EMAIL PROTECTED] wrote: 2008/1/21, Dave Hayes [EMAIL PROTECTED]: Matthew Dillon [EMAIL PROTECTED] writes: What, people didn't know we install a Makefile in /usr? Well, now you do! Er...maybe it's because I'm running 1.8.2 that I don't see one in /usr? When did you folks start doing this? 1.10 IIRC. Eh? I thought that was a joke. There's no /usr/Makefile on this box (1.11.0-PREVIEW). I'm pretty sure I used /usr/Makefile yesterday to run cvsup on a 1.10.1 box. I don't have access to that box right now. I'll check tonight. Maybe you need to install from a CD to get this makefile? Cheers, Nicolas
Re: cvsup
Matthew Dillon wrote: People shouldn't worry about server side overhead all that much. Cpu cycles are cheap and the cvs tree is completely cached in memory anyway. And the only effect that extra network bandwidth has is that it takes a little longer to run the operation. Now, granted, we don't want people to be downloading a whole copy's worth of network bandwidth every day, but rsync is close enough that I just don't care. One of the original reasons for using cvsup was so people could maintain local branches of the repository. I don't think people do this much anymore, if they do it all. Disk space is so cheap these days that keeping a master sync copy and a separate one for local work is not a big deal. -Matt Not that DragonFly is not already usable - but the time is approaching - perhaps Q3 or Q4 2008 - when enough 'good stuff' will converge to give it a distinct 'edge'. Especially if the 'major' *BSD doesn't soon find its way back to a more predictable and less fragile model. *Then* the bandwidth and all could very much matter. OTOH, enlisting more mirrors and managing them appropriately can probably happen rather rapidly if/as/when that sort of avalanche begins. PP Bill
Re: cvsup
Simon 'corecode' Schubert wrote: Matthew Dillon wrote: One of the original reasons for using cvsup was so people could maintain local branches of the repository. I don't think people do this much anymore, if they do it all. Disk space is so cheap these days that keeping a master sync copy and a separate one for local work is not a big deal. People use git or hg nowadays :) I just can't stop nagging, it is unbelievably useful, especially for team work. cheers simon Several such options can co-exist. But developers and 'deployer/maintainer' admins have different needs. - The devoloper needs fine-grain control of diverse options - The end-user / admin needs protection from breakage or stupidity, doesn't want to know anything about granularity beyond CPU family and release number. CVS has been the 'compromise' that is at least not harmful or overly demanding. Rather than 'nag' - set up what you want and see who joins or lends a hand. If it adds enough value to enough people, bandwidth and storage will be attracted to the solution. If not, not. Yet. ;-) Bill
Re: how to get dragonfly and freebsd source code
I'm reading a book about general architecture of microprocessors, and I am reading also a book of UltraSPARC microprocessor. I would like to learn how to program a processor, but in C language, and not in assembly! I would like to port a OS over UltraSPARC, for istance over DragonFly. Well I'm not so sure about websites containing everything you need to know, but there's a good order to doing these things. Like first learning a simple 8-bit Motorola CPU just to get familiar with the different parts of the processor and how it can be expanded. Then go on to MIPS, because it's coherent and learn about all the different optimization techniques. Then perhaps go on to x86 *shudder*. I'd recommend going to a University library. -- Robert Luciani [EMAIL PROTECTED] Chalmers University of Technology, SWE Department of Computer Science and Engineering -- only the paranoid will survive
Re: rsync and new mirroring tool (was cvsup)
Vincent Stemen wrote: sites += crater.dragonflybsd.org::dragonfly_cvs could you please not mirror off crater? Matt's link is quite resource constrained and should mainly be used for feeding mirrors and developers. Typing in a shell with high latency sucks :) cheers simon
Re: cvsup
Bill Hacker wrote: CVS has been the 'compromise' that is at least not harmful or overly demanding. CVS *is* harmful. I can't run a patch and work on a different issue myself - I'll mix both. Or I'll have to check out into another tree and lose the patch. Rather than 'nag' - set up what you want and see who joins or lends a hand. It is really cumbersome to keep any repo synchronized, especially if you want to have a nice repo which reflects vendor branches correctly. Basically all manual CVS interference has to be dealt with either in the tool or manually. If it adds enough value to enough people, bandwidth and storage will be attracted to the solution. Bandwidth and storage isn't the issue. I can develop forever in my git repo, and nobody might ever notice. And it won't magically make the project switch from CVS. cheers simon
Re: cvsup
Nicolas Thery wrote: What, people didn't know we install a Makefile in /usr? Well, now you do! Er...maybe it's because I'm running 1.8.2 that I don't see one in /usr? When did you folks start doing this? 1.10 IIRC. Eh? I thought that was a joke. There's no /usr/Makefile on this box (1.11.0-PREVIEW). I'm pretty sure I used /usr/Makefile yesterday to run cvsup on a 1.10.1 box. I don't have access to that box right now. I'll check tonight. Maybe you need to install from a CD to get this makefile? I guess so. Nothing does a make distribution except for mergemaster, and mergemaster doesn't merge /usr, I think. cheers simon
Re: cvsup
Simon 'corecode' Schubert wrote: Bill Hacker wrote: CVS has been the 'compromise' that is at least not harmful or overly demanding. CVS *is* harmful. To you, and other running experimental differences, perhaps so.. I can't run a patch and work on a different issue myself - I'll mix both. Or I'll have to check out into another tree and lose the patch. Indeed. And have to go find it and manually re-apply, and/or alter and re-apply 'coz it no longer fits quite tha same on code that has moved on in other details. But unless and until the patch is vetted and accepted into the mainstream that is exactly what a 'production' user wants. As few surprises as possible. As said - developers and production users have different priorities and CVS is a fairly effective compromise - ELSE it would have been scrapped long ago by a lot more projects than have done so to date. The alternatives are no longer new, nor are they without their own set of irritants. Rather than 'nag' - set up what you want and see who joins or lends a hand. It is really cumbersome to keep any repo synchronized, especially if you want to have a nice repo which reflects vendor branches correctly. Understood. But *any* repo and any toolset needs effort. Basically all manual CVS interference has to be dealt with either in the tool or manually. Alternatives may provide more comfortable knobs and buttons - but AFAIK, none of them yet read minds, let alone cover the sharp edges. If it adds enough value to enough people, bandwidth and storage will be attracted to the solution. Bandwidth and storage isn't the issue. I can develop forever in my git repo, and nobody might ever notice. And it won't magically make the project switch from CVS. cheers simon From tracking your work, I fully appreciate that you have made a great deal of effort, committed a lot of time and resources, and delivered much valuable code - so yes = anything that removes barriers to that gets some support. But if your peer contributors - who must have nearly identical concerns - don't yet see CVS as a target for 'real soon now' replacement, there must not (yet) be an overwhelming case for change. Change can't take place until it is possible for those involved to eval both tools side-by-side - on DragonFly, not 'other project x' - until they are convinced the advantage is worthwhile AND will not make it harder in general to use. I'm not defending CVS in particular. I'm just saying if *most* folks don't see whatever as broken a fix won't get a lot of followers. .or we would have left 'C' for something else about fifteen years ago, let alone the x86 archeologitecture. ;-) Bill
Re: cvsup
On Mon, 21 Jan 2008 13:59:12 +0100 Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Nicolas Thery wrote: Maybe you need to install from a CD to get this makefile? I guess so. Nothing does a make distribution except for mergemaster, and mergemaster doesn't merge /usr, I think. Hmm, I haven't used mergemaster since the upgrade target went into /usr/src/Makefile to replace it. I'm mildly surprised to find it's still in the system, is it of any actual use ? -- C:WIN | Directable Mirror Arrays The computer obeys and wins.| A better way to focus the sun You lose and Bill collects. |licences available see |http://www.sohara.org/
Re: cvsup
Steve O'Hara-Smith wrote: Maybe you need to install from a CD to get this makefile? I guess so. Nothing does a make distribution except for mergemaster, and mergemaster doesn't merge /usr, I think. Hmm, I haven't used mergemaster since the upgrade target went into /usr/src/Makefile to replace it. I'm mildly surprised to find it's still in the system, is it of any actual use ? Absolutely. There is no other way to merge config files, for instance ssh, sshd, inetd, etc. cheers simon
Re: cvsup
Bill Hacker wrote: I can't run a patch and work on a different issue myself - I'll mix both. Or I'll have to check out into another tree and lose the patch. Indeed. And have to go find it and manually re-apply, and/or alter and re-apply 'coz it no longer fits quite tha same on code that has moved on in other details. And once you've applied it, it is mixed with your existing changes. That's the main problem. But unless and until the patch is vetted and accepted into the mainstream that is exactly what a 'production' user wants. A production user doesn't want patches or something else. He wants working binaries. As said - developers and production users have different priorities and CVS is a fairly effective compromise - ELSE it would have been scrapped long ago by a lot more projects than have done so to date. No, that's not true. It's just that developers are lazy and don't want to learn new, potentially better tools. They are also conservative and don't want to change one tool for the other without real benefit. Several projects did the mistake to convert from cvs to svn, which didn't really improve productivity (I guess). Rather than 'nag' - set up what you want and see who joins or lends a hand. It is really cumbersome to keep any repo synchronized, especially if you want to have a nice repo which reflects vendor branches correctly. Understood. But *any* repo and any toolset needs effort. No doubt. The differences, however, are orders of magnitude. Basically all manual CVS interference has to be dealt with either in the tool or manually. Alternatives may provide more comfortable knobs and buttons - but AFAIK, none of them yet read minds, let alone cover the sharp edges. Oh yes, they do cover sharp edges. They might have other, different ones, but not as many and not as sharp (I'm obviously biased). But if your peer contributors - who must have nearly identical concerns - don't yet see CVS as a target for 'real soon now' replacement, there must not (yet) be an overwhelming case for change. Oh yes, everybody who EVER tried adding third party software to the repo, or rather kept maintaining it, has been swearing on CVS. Even Matt decided that CVS was evil and started the whole patch thing. The patches helped on one side but are hurting on the other side - much more. The real salvation is a version control system which will help the developers in their tasks - not stand them in the way. Change can't take place until it is possible for those involved to eval both tools side-by-side - on DragonFly, not 'other project x' - until they are convinced the advantage is worthwhile AND will not make it harder in general to use. No doubt. Bear in mind that every new tool needs some effort to learn. This means that everybody involved has to accept the fact that they need to put some effort in in order to be able to fairly evaluate the tool. So a learning curve has to be expected. I'm not defending CVS in particular. I'm just saying if *most* folks don't see whatever as broken a fix won't get a lot of followers. People still program in C. People keep writing shell scripts. *Most* people don't realize the shortcomings of the tools they are using because they a) they don't reflect on their workflows and they are b) too lazy to check out alternatives to realize there is help. .or we would have left 'C' for something else about fifteen years ago, let alone the x86 archeologitecture. You exactly nailed the point. People don't want to move. They don't want to learn. Even if the alternative would be orders of magnitude better. cheers simon
Re: cvsup
:... : Hmm, I haven't used mergemaster since the upgrade target went : into /usr/src/Makefile to replace it. I'm mildly surprised to find it's : still in the system, is it of any actual use ? : :Absolutely. There is no other way to merge config files, for instance :ssh, sshd, inetd, etc. : :cheers : simon Er. Well, I haven't kept it up to date for years. 'make upgrade' (after an installworld) is all I use. -Matt Matthew Dillon [EMAIL PROTECTED]
Re: rsync and new mirroring tool (was cvsup)
On 2008-01-21, Simon 'corecode' Schubert [EMAIL PROTECTED] wrote: Vincent Stemen wrote: sites += crater.dragonflybsd.org::dragonfly_cvs could you please not mirror off crater? Matt's link is quite resource constrained and should mainly be used for feeding mirrors and developers. Typing in a shell with high latency sucks :) cheers simon Understood. I suspected something like that might be the case since it was not in the download site list on dragonflybsd.org. That is why I put it last :-). Mirror will use the first site in the list by default unless you specify one of the others on the command line. For the default config file, I could do one of three options: 1. Leave it last in the list and add what you said as a comment to make it convenient for developers and mirrors who might need to use it. 2. Same as 1 but have crater commented out by default. 3. Remove crater altogether from the default configuration file. What would you guys prefer?
Re: rsync and new mirroring tool (was cvsup)
On Mon, Jan 21, 2008 at 09:00:31PM +, Vincent Stemen wrote: 1. Leave it last in the list and add what you said as a comment to make it convenient for developers and mirrors who might need to use it. 2. Same as 1 but have crater commented out by default. 3. Remove crater altogether from the default configuration file. What would you guys prefer? #3 pgpSPegmJK3t1.pgp Description: PGP signature
Re: cvsup
Simon 'corecode' Schubert wrote: .. Oh yes, everybody who EVER tried adding third party software to the repo, or rather kept maintaining it, has been swearing on CVS... Heh. That's ambiguous in colloquial English, which admittedly makes no sense and therefore is difficult to learn. You wanted to say 'swearing at', as in hurling epithets 'at' someone. There is also 'swearing by' something, which means exactly the opposite, e.g. 'I swear by DragonFly -- it's the best OS I've used'. There is also 'swearing on' a Bible to take an oath -- I suppose because you put your right hand 'on' the Bible during the oath. Anyway, you created a DragonFly-git repo at http://repo.or.cz but it is out of date now. They do offer an automatic update service, which sounds very good: In the mirror mode, we will check the remote repository at the URL you give us every hour and if we spot any changes, we will grab them, mirror them and show them in our gitweb interface. Is there any reason not to take advantage of their very kind offer?
Re: cvsup
walt wrote: Anyway, you created a DragonFly-git repo at http://repo.or.cz but it is out of date now. They do offer an automatic update service, which sounds very good: In the mirror mode, we will check the remote repository at the URL you give us every hour and if we spot any changes, we will grab them, mirror them and show them in our gitweb interface. Is there any reason not to take advantage of their very kind offer? It is running in mirror mode, but for that I'd have to keep updating the git repo I used to generate upstream. Now my repo converter is fairly complete, but it missed one or the other manual repo activity :/, so the git repo is unhappy right now. Plus there is a bug somewhere which makes it eat memory (when converting freebsd), like homer is eating donuts. So either somebody will give me a hand or it'll have to wait until I have enough time to fix it myself. cheers simon -- Serve - BSD +++ RENT this banner advert +++ASCII Ribbon /\ Work - Mac +++ space for low €€€ NOW!1 +++ Campaign \ / Party Enjoy Relax | http://dragonflybsd.org Against HTML \ Dude 2c 2 the max ! http://golden-apple.biz Mail + News / \
Re: cvsup
Simon 'corecode' Schubert wrote: Bill Hacker wrote: *trimmed* The bottom line - viewing it not a a coder, which I haven't been for around 30 years - but as a Manager of scarce resources - primarily *time*, and not even my own in this case - is that: - Apparent: No readily available 'one size' fits all needs well enough to justify excluding others. - Apparent: There is enough gain to justify running parallel options - Suspected: There is NOT PRESENTLY enough 'assured' gain to attract the support needed to run more than one (or even *any*) as well as they need to be run order to secure value. See the comment about the existing git repository not being current... A good idea, bed-ridden, is less mobile a bandaged-up idea on crutches. Even so - it should NOT be necessary to chose 'one and only' one, e.g. move off CVS to else-thing. The missing resource is not addressed by taking any one coder away from coding to maintain a repository - nor creating a new toolset from scratch. It *may* be solvable by enlisting several coders to digress long enough to invest in the automation that makes it possible for less effort in future to keep at least one alternative repository system in top form. I do not know if that should be git or some other CVS alternative. But the payback has to become apparent in months if not weeks - no more than that - ELSE it is 'faster' to continue to deal with the Devil one knows than retrain - and *still* struggle. Even so - someone with admin skills AND understanding of what matters AND how it has to work, AND daily availability to stay on top of it, i.e. almost by definition NOT a coder - would be needed to keep it sorted. That's the issue as I see it - need for what we 'Politically Incorrect' old farts used to (be allowed to) call a 'Gal Friday'. - but analysing a barrier isn't the same as removing it, and I am in no better position to actually fix it than anyone else that has yet spoken. That said - while one cannot 'herd cats' or 'direct' the efforts of volunteers... perhaps 'will' and 'need' can enlist enough consensus to move a solution out of 'wish for' and into 'useful' land. pkgsrc revanche. It has paid-off. ELSE - do the best that can be done with existing tools for a while longer. Bill
Re: rsync and new mirroring tool (was cvsup)
:Understood. I suspected something like that might be the case since it :was not in the download site list on dragonflybsd.org. That is why :I put it last :-). : :Mirror will use the first site in the list by default unless you specify :one of the others on the command line. For the default config file, :I could do one of three options: : :1. Leave it last in the list and add what you said as a comment to : make it convenient for developers and mirrors who might need to : use it. :2. Same as 1 but have crater commented out by default. :3. Remove crater altogether from the default configuration file. : :What would you guys prefer? #2. It's ok for crater to be listed, but it should be commented out for now. Manual use of crater is fine, its the automatic cron jobs that I'd like to avoid :-) -Matt Matthew Dillon [EMAIL PROTECTED]
