Hi Martin Martin Hejl schrieb: > Hi Erich, > ...
> Sorry for the late reply. Ahhh... no sweat > > For the sources, it's quite simple, as long as you stay away from CVS > import. You may skip the first step if you already have a checkout that > contains src/bering-uclibc/contrib - just make sure you run > "cvs update -d" to make sure it's fully up to date. > > For binaries (modules or lrp files), the approach is the same, just for > a different directory - for lrp files, it's > bin/packages/uclibc-0.9/28/contrib - but I don't know where modules > would go - you'll have to ask Eric on how that should be handled. > > * cvs -z3 -d:ext:[EMAIL PROTECTED]:/cvsroot/leaf \ > co src/bering-uclibc/contrib > * cd src/bering-uclibc/contrib > * mkdir yourNewPackageDir > * cvs add yourNewPackageDir > * cp yourfiles yourNewPackageDir/ > * check that only the files you want to add to cvs ended up in > yourNewPackageDir/ (no backup files created by editors, for example) > * cvs add yourNewPackageDir/* > * cvs commit yourNewPackageDir > * to check if everything was checked in, run > "cvs update yourNewPackageDir" - if there are files prefixed with "?" > in the output of the command, those didn't get checked in Thank you, the biggest problem was to find the correct place for a module, in this case the r1000 thing. I don't know if a module sent to contrib gets included into the lib/modules tree/tarball. I don't mind maintaining it myself, it might just make life easier for everyone if I don't have to send it to the people that have this hardware but do not get involved in the compile business. > > Note - "cvs add" doesn't work recursively, so if "yourfiles" contains > directories, their contents have to be added separately. > In general, be careful not to add directories by mistake - directories > added by mistake have to be removed by SF staff, we have no way of > removing them ourselves. Yes I ran into this one. I was running CVS myself for a number of years and having admin access makes life a lot easier. > > That's it - a little more typing than using "cvs import", but this way, > you can be sure things end up in the right place (and there's less > chance of accidentally checking in temporary files). Indeed. would you guys be thinking about a hierarchically flat CVS which holds a complete tree of the development environment? Having read lately about trouble getting the buildenv set up convinces me that a flat CVS could lower maintenance effort. I understand the idea of keeping the various sources apart, but the latest development in the GPL appears to make it mandatory to keep sources of everything anyway, so we cannot rely on external repositories. I believe it would also be easier to handle comprehensive versioning as everything may depend on a certain version of the development environment. Thanks Erich ------------------------------------------------------------------------- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now >> http://get.splunk.com/ _______________________________________________ leaf-devel mailing list leaf-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/leaf-devel
