Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote:
At 9:18 PM +0200 1/29/03, Sheldon Hearn wrote:
Can anyone think of a good way to implement an installworld /
installkernel seat-belt for source upgrades from stable to current?
What I'm looking for is a way for installworld and installkernel
in the current source to look for some signature in the target
filesystem that suggests that a stable world is about to be
upgraded to current.
How about requiring the user to touch some file in / or /boot which
indicates the branch-tag that's acceptable for installworlds? Then
you just need to propagate the tag from the 'cvs co' stage to some
file under /usr/src (such as /usr/src/CVS/Tag ).
That's exactly the case when upgrading from -stable to -current.
Installkernel should be the first thing to install, and it will
complain with:
: You must set up a /boot/device.hints file first.
So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the
second file has to be typed in by the user, by hand. Eh, maybe
/boot isn't the right place for it. Well, maybe /.branch_tag
[1] Guess who just trashed a stable installation for the 3rd time
in 3 years today?
Well, I almost would have done the same thing in my latest 4.7
install, but when I cd'ed into sys/i386/conf I thought it was
odd that there was a GENERIC.hints file sitting there... If
it wasn't for my desire to compile an SMP kernel instead of
GENERIC, I might not have noticed until it was too late!!
We could expand the ``installcheck'' target in Makefile.inc1 to
ask the user if he actually wants to upgrade from `uname -r`
(the running kernel) to what appears to be an argument to
cvs update in the ``update'' target in the same makefile
(-A for HEAD, and RELENG_* otherwise).
Running uname(1) from ${.OBJDIR} is a bad idea as it may not be
runnable at all.
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg51330/pgp0.pgp
Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 11:33:16PM -0500, Mike Makonnen wrote: On Thu, 30 Jan 2003 20:05:06 -0800 David Schultz [EMAIL PROTECTED] wrote: That's a great answer...to a different question. ;-) Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. Er, rlog is just a synonym for log. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software AG, [EMAIL PROTECTED] FreeBSD committer, +380.652.512.251Simferopol, Ukraine http://www.FreeBSD.org The Power To Serve http://www.oracle.com Enabling The Information Age msg51331/pgp0.pgp Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote:
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away /usr/src
:and fetching a new copy from a CVS server, but I'm sure this is
:far from ideal for the people who pay for that server's bandwidth.
:
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
cvsup gets me everything I need to track and compile both current and
stable.
I don't want to be forced into using cvs when there's a better tool
available (for some definition of better). I get paid to use cvs at
work, and that's how I know to choose something else...
For a while, I used to grab the whole repo (with cvsup), and used cvs
to get current and stable out of it, but now I consider that a waste
of space/time, and have reverted to just using cvsup to get the tags I
want.
I'm not a FreeBSD developer, and very rarely (just a handful of times)
have had to modify existing stuff to do what I want, so I don't need
my own repo to commit to. With that, disappers any need to use cvs.
Perhaps you can explain why cvsup is the wrong answer...
I don't know about Steve, but cvsup is the wrong answer for me
because it's a mirroring tool and not a version control tool.
Among the things I would like to do are:
- Update to a specific version of a specific file from the
repository.
- Generate a diff between two revisions in the repository,
or between a version in the repository and some local
patches of my own.
- View logs for particular files.
I asked the question in hopes that there would be some neat
feature of cvsup that mocked up some CVS metadata for me, but
since nobody has mentioned any such thing, I guess I'm out of
luck. Mirroring the entire repository is not an option on
machines with less than 6 GB of spare disk.[1] Transferring the
entire source tree over the network via anoncvs is suboptimal when
all I really want is a few kilobytes of 'CVS' subdirectories.
But I guess it will have to do for now.
[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.
Well then learn how to use anoncvs?
Cheers,
--
Ruslan Ermilov Sysadmin and DBA,
[EMAIL PROTECTED] Sunbay Software AG,
[EMAIL PROTECTED] FreeBSD committer,
+380.652.512.251Simferopol, Ukraine
http://www.FreeBSD.org The Power To Serve
http://www.oracle.com Enabling The Information Age
msg51332/pgp0.pgp
Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
Date: Thu, 30 Jan 2003 21:58:15 -0800 From: David Schultz [EMAIL PROTECTED] I asked the question in hopes that there would be some neat feature of cvsup that mocked up some CVS metadata for me, but since nobody has mentioned any such thing, I guess I'm out of luck. Mirroring the entire repository is not an option on machines with less than 6 GB of spare disk.[1]... In the interest of providing empirical data, since this thread is being archived and someone might see the above and come to the conclusion that 6 GB of space is required for a full mirror of the CVS repository, I offer: freebeast(4.7-S)[1] cd /cvs freebeast(4.7-S)[2] du -ks . 1649982 . freebeast(4.7-S)[3] cd /usr/src freebeast(4.7-S)[4] !2 du -ks . 321999 . freebeast(4.7-S)[5] That's a little over 1.6 GB for the CVS repo itself, plus 350 MB for the /usr/src working directory. (I do have a little bit of extra stuff in the CVS repository for local things, but it isn't significant, and certainly doesn't change the point, which is that about 2 GB appears to be adequate at this time.) [1] When the system is an aging dual PPro or 200MHz Alpha using SCSI, buying new drives is not practical. Given the price of hardware, it might be worth considering cobbling up a separate box for the purpose. You may have done this, and decided that it's not worth the cost, or is otherwise inappropriate or ineffective. That's fine: it's your problem and your resources, so how you choose to allocate them is (and should be) your decision. But any solution will cost some resources. For me, keeping a local mirror of the CVS repository works well enough that I'm rather surprised that it isn't done by more folks. Cheers, david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. david (links to my resume at http://www.catwhisker.org/~david) -- David H. Wolfskill [EMAIL PROTECTED] I have no confidence in results obtained through the use of Microsoft products. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Friday 31 January 2003 00:58, David Schultz wrote:
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away
:/usr/src and fetching a new copy from a CVS server, but I'm sure
:this is far from ideal for the people who pay for that server's
:bandwidth.
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
[...Chris Vance explains why cvsup is all he needs...]
Perhaps you can explain why cvsup is the wrong answer...
I don't know about Steve, but cvsup is the wrong answer for me
because it's a mirroring tool and not a version control tool.
Among the things I would like to do are:
- Update to a specific version of a specific file from the
repository.
Anoncvs will let you do this.
cvs -D $ANONCVSROOT co -r$REVISION -d $WHERE_I_WANT_IT $WHERE_IT_IS
- Generate a diff between two revisions in the repository,
You can use CVSweb for this quite ably. That's not a great
solution for generating patches, but it's decent enough for trolling
around the repo.
or between a version in the repository and some local
patches of my own.
For that, you'd most easily check out the directory in which the
files in question live, copy your local version into it, and use cvs
diff. The repo information is cached in the CVS/ subdir, so it all
works nicely:
cvs diff -u myfile.c
- View logs for particular files.
CVSweb is your friend. http://cvsweb.freebsd.org
[...old machine, limited disk space, mirroring the entire repo
infeasible...]
Transferring the entire source tree over the network via anoncvs is
suboptimal when all I really want is a few kilobytes of 'CVS'
subdirectories. But I guess it will have to do for now.
It's unnecessary. Use the -d option to cvs co to check out the
subdirectories into a convenient place.
[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.
If you can afford it, retire the box to mail/firewall duty. A
bare-bones 2.4GHz P4 system can be had for $500US if you shop hard.
--
Chris BeHanna http://www.pennasoft.com
Principal Consultant
PennaSoft Corporation
[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Ruslan Ermilov [EMAIL PROTECTED]: On Thu, Jan 30, 2003 at 09:58:15PM -0800, David Schultz wrote: I don't know about Steve, but cvsup is the wrong answer for me because it's a mirroring tool and not a version control tool. Among the things I would like to do are: - Update to a specific version of a specific file from the repository. - Generate a diff between two revisions in the repository, or between a version in the repository and some local patches of my own. - View logs for particular files. I asked the question in hopes that there would be some neat feature of cvsup that mocked up some CVS metadata for me, but since nobody has mentioned any such thing, I guess I'm out of luck. Mirroring the entire repository is not an option on machines with less than 6 GB of spare disk.[1] Transferring the entire source tree over the network via anoncvs is suboptimal when all I really want is a few kilobytes of 'CVS' subdirectories. But I guess it will have to do for now. [1] When the system is an aging dual PPro or 200MHz Alpha using SCSI, buying new drives is not practical. Well then learn how to use anoncvs? I use anoncvs. My question was, given a source or ports tree without any CVS metadata, is there a way to obtain the tiny corresponding CVS/Entries and CVS/Repository files without checking out an entirely new copy of the tree via a busy, often overloaded, anoncvs server. Keep in mind that I'm not asking a ``can it be done?'' question. I've been doing it for years. Rather, I'm asking, ``can it be done more efficiently?'' So far, the best answer I've received is ``mirror the repository locally'' (thank you, David), which I already do on one machine to maintain a local branch and will consider doing on others. I have also considered writing a script to parse embedded $FreeBSD$ tags out of source files and mock up a CVS/Entries and CVS/Repository based on that information. Perhaps I will try that and see if it works passably well. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Giorgos Keramidas [EMAIL PROTECTED]: On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Actually, 'cvs export' does the opposite of what I want to do. But thank you for mentioning it, because it's a good way to explain what I'm trying to do, so people don't keep assuming that my problem is not knowing how to use CVS. 'cvs checkout': create a copy of the sources AND CVS's administrative directories 'cvs export': just create a copy of the sources What I want to do: just create the administrative directories I'm aware that making CVS magically discover what version I have is a bit much to ask for, so I'm willing to tell it what tag to use. Unfortunately, I don't think the facility I want exists, but I'm going to try to implement a workaround when I have a moment. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
* De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ] [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Further, export -d somedir might be useful in this situation to get the files where you want them, though sometimes -d does not DWIM, so I'm not sure :) -- Juli Mallett [EMAIL PROTECTED] AIM: BSDFlata -- IRC: juli on EFnet OpenDarwin, Mono, FreeBSD Developer ircd-hybrid Developer, EFnet addict FreeBSD on MIPS-Anything on FreeBSD To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Juli Mallett [EMAIL PROTECTED]: * De: Giorgos Keramidas [EMAIL PROTECTED] [ Data: 2003-01-31 ] [ Subjecte: Re: Seat-belt for source upgrades from stable to current ] On 2003-01-30 21:38, David Schultz [EMAIL PROTECTED] wrote: Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. # cd /tmp # cvs -d 'repo magic' export -rHEAD src/file/i/want.c Does `cvs export' do the trick for you? Further, export -d somedir might be useful in this situation to get the files where you want them, though sometimes -d does not DWIM, so I'm not sure :) That works when the revision has a symbolic tag associated with it, but export seems to be picky and won't do numeric revision numbers of particular files. I guess I could always go by date. And yes, -d is picky, too; you can't export into your working directory. Still, not bad... It doesn't address the entire problem I mentioned before, because I still want to do diffs between local revisions and the repository. This thread is just a subthread of the original thread in which I guess we're talking about how to do a 'cvs update' without a copy of the repository. (Sorry Giorgos, your idea actually works for updates, just not for the original question I was asking. I was confused. ENOSLEEP.) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On 2003-01-29 21:55, Steve Kargl [EMAIL PROTECTED] wrote: On Thu, Jan 30, 2003 at 12:47:13AM -0500, Garance A Drosihn wrote: At 8:59 PM -0800 1/29/03, Steve Kargl wrote: You don't need a special file to indicate what version of FreeBSD you have. uname -r tells you. Actually, one thing I don't know is how this would work when it comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0). What does uname show for the security branches? Just wondering. I don't run 4.x, so I do know. ;-) I suspect on a 4.x system, you'll get 4.x- where is either FreeBSD or STABLE. 4.7-RELEASE-p1 4.7-RELEASE-p2 ... You can find the relevant script in /usr/src/sys/conf/newvers.sh - Giorgos To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote: : How about requiring the user to touch some file in / or /boot which : indicates the branch-tag that's acceptable for installworlds? Then : you just need to propagate the tag from the 'cvs co' stage to some : file under /usr/src (such as /usr/src/CVS/Tag ). Some of use cvsup and won't have CVS/Tag. -- Christopher Vance To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote:
: How about requiring the user to touch some file in / or /boot which
: indicates the branch-tag that's acceptable for installworlds? Then
: you just need to propagate the tag from the 'cvs co' stage to some
: file under /usr/src (such as /usr/src/CVS/Tag ).
Some of use cvsup and won't have CVS/Tag.
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Wed, Jan 29, 2003 at 10:35:40PM -0500, Garance A Drosihn wrote:
: How about requiring the user to touch some file in / or /boot which
: indicates the branch-tag that's acceptable for installworlds? Then
: you just need to propagate the tag from the 'cvs co' stage to some
: file under /usr/src (such as /usr/src/CVS/Tag ).
Some of use cvsup and won't have CVS/Tag.
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
anoncvs
See the handbook for info.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Steve Kargl [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
anoncvs
See the handbook for info.
That's a great answer...to a different question. ;-)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Thu, 30 Jan 2003 20:05:06 -0800 David Schultz [EMAIL PROTECTED] wrote: That's a great answer...to a different question. ;-) Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. Cheers. -- Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc [EMAIL PROTECTED] | Fingerprint: D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9 msg51322/pgp0.pgp Description: PGP signature
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
Thus spake Steve Kargl [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
OT: Is there a good way to get the CVS metadata in /usr/src and
/usr/ports without transferring the entire source tree over the
network? On some machines, I'd like to be able to do a CVS
{diff,log,update} now and then, but I don't have the disk space
for the entire repository. I usually end up blowing away /usr/src
and fetching a new copy from a CVS server, but I'm sure this is
far from ideal for the people who pay for that server's bandwidth.
anoncvs
See the handbook for info.
That's a great answer...to a different question. ;-)
It's the correct answer. I assumed that you knew
how to use cvs.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away /usr/src
:and fetching a new copy from a CVS server, but I'm sure this is
:far from ideal for the people who pay for that server's bandwidth.
:
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
cvsup gets me everything I need to track and compile both current and
stable.
I don't want to be forced into using cvs when there's a better tool
available (for some definition of better). I get paid to use cvs at
work, and that's how I know to choose something else...
For a while, I used to grab the whole repo (with cvsup), and used cvs
to get current and stable out of it, but now I consider that a waste
of space/time, and have reverted to just using cvsup to get the tags I
want.
I'm not a FreeBSD developer, and very rarely (just a handful of times)
have had to modify existing stuff to do what I want, so I don't need
my own repo to commit to. With that, disappers any need to use cvs.
Perhaps you can explain why cvsup is the wrong answer...
--
Christopher Vance
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Mike Makonnen [EMAIL PROTECTED]: Use the r version of the cvs commands (like cvs rlog and rdiff). They operate on the repository remotely, so you don't need to have the files checked out localy. That's a pretty good solution, and I use those occasionally. It would be a perfect solution if there were an 'rupdate', so I don't have to (cd /tmp; cvs co src/file/i/want.c) cp /tmp/src/file/i/want.c /where/i/want/it rm -rf /tmp/src all the time. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
Thus spake Christopher Vance [EMAIL PROTECTED]:
On Thu, Jan 30, 2003 at 09:07:11PM -0800, Steve Kargl wrote:
: On Thu, Jan 30, 2003 at 08:05:06PM -0800, David Schultz wrote:
: Thus spake Steve Kargl [EMAIL PROTECTED]:
: On Thu, Jan 30, 2003 at 07:09:16PM -0800, David Schultz wrote:
:OT: Is there a good way to get the CVS metadata in /usr/src and
:/usr/ports without transferring the entire source tree over the
:network? On some machines, I'd like to be able to do a CVS
:{diff,log,update} now and then, but I don't have the disk space
:for the entire repository. I usually end up blowing away /usr/src
:and fetching a new copy from a CVS server, but I'm sure this is
:far from ideal for the people who pay for that server's bandwidth.
:
:
: anoncvs
:
: See the handbook for info.
:
: That's a great answer...to a different question. ;-)
:
: It's the correct answer. I assumed that you knew
: how to use cvs.
cvsup gets me everything I need to track and compile both current and
stable.
I don't want to be forced into using cvs when there's a better tool
available (for some definition of better). I get paid to use cvs at
work, and that's how I know to choose something else...
For a while, I used to grab the whole repo (with cvsup), and used cvs
to get current and stable out of it, but now I consider that a waste
of space/time, and have reverted to just using cvsup to get the tags I
want.
I'm not a FreeBSD developer, and very rarely (just a handful of times)
have had to modify existing stuff to do what I want, so I don't need
my own repo to commit to. With that, disappers any need to use cvs.
Perhaps you can explain why cvsup is the wrong answer...
I don't know about Steve, but cvsup is the wrong answer for me
because it's a mirroring tool and not a version control tool.
Among the things I would like to do are:
- Update to a specific version of a specific file from the
repository.
- Generate a diff between two revisions in the repository,
or between a version in the repository and some local
patches of my own.
- View logs for particular files.
I asked the question in hopes that there would be some neat
feature of cvsup that mocked up some CVS metadata for me, but
since nobody has mentioned any such thing, I guess I'm out of
luck. Mirroring the entire repository is not an option on
machines with less than 6 GB of spare disk.[1] Transferring the
entire source tree over the network via anoncvs is suboptimal when
all I really want is a few kilobytes of 'CVS' subdirectories.
But I guess it will have to do for now.
[1] When the system is an aging dual PPro or 200MHz Alpha using
SCSI, buying new drives is not practical.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 09:18:22PM +0200, Sheldon Hearn wrote: Hi folks, Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. I want this because far too many people, far too frequently, update their source to HEAD by mistake and then end up with current when they really wanted stable. [1] If this can be done cleanly, I'd like to do it. If not, I don't want it to be a hack. So, ideas on infallible signatures? /usr/bin/uname -r /usr/obj/usr/src/usr.bin/uname/uname -r -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 9:18 PM +0200 1/29/03, Sheldon Hearn wrote: Can anyone think of a good way to implement an installworld / installkernel seat-belt for source upgrades from stable to current? What I'm looking for is a way for installworld and installkernel in the current source to look for some signature in the target filesystem that suggests that a stable world is about to be upgraded to current. How about requiring the user to touch some file in / or /boot which indicates the branch-tag that's acceptable for installworlds? Then you just need to propagate the tag from the 'cvs co' stage to some file under /usr/src (such as /usr/src/CVS/Tag ). So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the second file has to be typed in by the user, by hand. Eh, maybe /boot isn't the right place for it. Well, maybe /.branch_tag [1] Guess who just trashed a stable installation for the 3rd time in 3 years today? Well, I almost would have done the same thing in my latest 4.7 install, but when I cd'ed into sys/i386/conf I thought it was odd that there was a GENERIC.hints file sitting there... If it wasn't for my desire to compile an SMP kernel instead of GENERIC, I might not have noticed until it was too late!! -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 8:05 PM -0800 1/29/03, Steve Kargl wrote: On Wed, Jan 29, 2003, Garance A Drosihn wrote: How about requiring the user to touch some file in / or /boot which indicates the branch-tag that's acceptable for installworlds? Then you just need to propagate the tag from the 'cvs co' stage to some file under /usr/src (such as /usr/src/CVS/Tag ). So, maybe compare /usr/src/CVS/Tag to /boot/BRANCH_TAG, where the second file has to be typed in by the user, by hand. Eh, maybe /boot isn't the right place for it. Well, maybe /.branch_tag I don't have a /usr/src/CVS directory. I suspect most people don't pulldown the cvs repository. Well, then, just have the branch-tag show up in some file that is somewhere else in the /usr/src tree. It ain't hard to do. This new check would not go into effect until you updated your /usr/src tree, and the same update could bring in a /usr/src/BRANCH file. uname(1) works on both 4.7 and 5.0. This seems like a trivial problem to fix. If you use something fixed like uname, then what does one do once they *DO* want to switch from one branch to another one? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Wed, Jan 29, 2003 at 11:21:39PM -0500, Garance A Drosihn wrote:
At 8:05 PM -0800 1/29/03, Steve Kargl wrote:
uname(1) works on both 4.7 and 5.0. This seems
like a trivial problem to fix.
If you use something fixed like uname, then what does one do once
they *DO* want to switch from one branch to another one?
Compare output from /usr/bin/uname -r to ${OBJDIR}/usr.bin/uname/uname -r.
If the strings are the same, then install. If the strings are different
or an error occurs either abort the install or wait for keyboard input
to continue the installation.
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 8:59 PM -0800 1/29/03, Steve Kargl wrote:
On Wed, Jan 29, 2003 at 11:21:39PM -0500, Garance A Drosihn wrote:
At 8:05 PM -0800 1/29/03, Steve Kargl wrote:
uname(1) works on both 4.7 and 5.0. This seems
like a trivial problem to fix.
If you use something fixed like uname, then what does one do once
they *DO* want to switch from one branch to another one?
Compare output from /usr/bin/uname -r to ${OBJDIR}/usr.bin/uname/uname -r.
If the strings are the same, then install. If the strings are different
or an error occurs either abort the install or wait for keyboard input
to continue the installation.
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
Indeed, I know what uname -r does.
I also know that it changes when freebsd goes from 4.6 to 4.7,
even though the user has not changed what branch (RELENG_4)
they intend to be pulling updates from when we decide to change
the name.
I understand what you're advocating, I just don't prefer it. On
the other hand, I agree that would also work better than what we
have now. I only want to offer some suggestions, and let someone
else (sheldon?) decide what they wanted to implement.
--
Garance Alistair Drosehn= [EMAIL PROTECTED]
Senior Systems Programmer or [EMAIL PROTECTED]
Rensselaer Polytechnic Instituteor [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 8:59 PM -0800 1/29/03, Steve Kargl wrote: You don't need a special file to indicate what version of FreeBSD you have. uname -r tells you. Actually, one thing I don't know is how this would work when it comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0). What does uname show for the security branches? Just wondering. The uname idea is fine with me, if someone wants to implement it that way. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
On Thu, Jan 30, 2003 at 12:47:13AM -0500, Garance A Drosihn wrote:
At 8:59 PM -0800 1/29/03, Steve Kargl wrote:
You don't need a special file to indicate what version of
FreeBSD you have. uname -r tells you.
Actually, one thing I don't know is how this would work when it
comes to RELENG_4 vs RELENG_4_0 (since I don't run RELENG_4_0).
What does uname show for the security branches? Just wondering.
The uname idea is fine with me, if someone wants to implement it
that way.
I don't run 4.x, so I do know. ;-)
I suspect on a 4.x system, you'll get 4.x-
where is either FreeBSD or STABLE. To distinguish
between 4.x and 5.x, all we need the first character.
In actuality, if you build a 5.0 world on a 4.x system,
I think ${OBJDIR}/usr.bin/uname/uname will die with an
error when the shared libraries aren't found.
--
Steve
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Seat-belt for source upgrades from stable to current
At 9:55 PM -0800 1/29/03, Steve Kargl wrote: I don't run 4.x, so I do know. ;-) I suspect on a 4.x system, you'll get 4.x- where is either FreeBSD or STABLE. To distinguish between 4.x and 5.x, all we need the first character. So, uname -r shows 4.7-FreeBSD for the security branch? If someone intends to be running the security branch, isn't it just as much of an error if they mistakenly install the 4-stable branch when they didn't want that? I think we have to check more than the first character. Note that I'm also thinking about cases were people are doing buildworlds on one machine, and then NFS-exporting that to do installworlds on other machines. I don't do that, but we might as well try to help as many people as possible with a change like this. I'm not saying that I know what that *is*, just that I'm trying to toss out a variety of ideas... :-) -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
