Re: Can I maintain config files as a CVS branch w/o messing up mergemaster etc.?

From: David Wolfskill (david_at_catwhisker.org)
Date: 04/30/04

  • Next message: Ruslan Ermilov: "Re: ng_bridge(4) has an easily exploitable memory leak" 
    Date: Thu, 29 Apr 2004 18:35:05 -0700 (PDT)
To: dgl@dlee.org, freebsd-stable@freebsd.org

    >Date: Thu, 29 Apr 2004 17:59:18 -0400
    >From: Doug Lee <dgl@dlee.org>
    >To: freebsd-stable@freebsd.org
    >Subject: Can I maintain config files as a CVS branch w/o messing up
    >Sender: owner-freebsd-stable@freebsd.org

    >I track STABLE and wonder if there's a clean way for me to use CVS to
    >do it (without having the whole CVS repo on my box).

    I also track -STABLE (as well as -CURRENT); however, my approach is to
    go ahead and maintain a private mirror of the CVS repo. (Actually, I do
    this on a couple of boxen, one of which is my laptop. The CVS repo on
    my laptop is thus actually a mirror of my private mirror.)

    Disk space is not all that expensive nowadays; the repo appears to take
    right around 2 GB:

    g1-15(4.10-P)[1] cd /cvs/freebsd/
    g1-15(4.10-P)[2] du -ks .
    2084040 .
    g1-15(4.10-P)[3]

    And I find it handy to have the repo on my laptop. (I run a Web server
    on it, too, so I can play with cvsweb locally, even if I'm disconnected
    from the Net.)

    >Example: I
    >modify /etc/rc.firewall and then cvsup my way up to a more current
    >STABLE. The normal tactic is to hand-merge via mergemaster, but I
    >think there should be a way for me to get CVS to do it:

    Yes, well.... I could be wrong about this, but I would expect that
    having different files in the same (CVS working) directory have their
    histories &c. in different CVS repositories would be awkward, at best.
    After all, a given directory may have at most one "CVS" subdirectory.

    That said, I do this sort of thing for /usr/src/sys/i386/conf: the
    original files I leave alone; my working kernel config files are merely
    represented by symlinks (in my case, to /usr/local/src/kernels/...), and
    the latter hierarchy is in a local CVS repository (parallel to the
    FreeBSD one). (Source control is A Good Thing.)

    > cvsup/mergemaster for fresh system (hypothetical of course)
    > (current /etc/rc.firewall is now exactly the STABLE version)
    > make local mods
    > cvs commit mods (locally)
    > cvsup
    > use CVS instead of Mergemaster to merge in changes since last cvsup

    Along with the above, I use mergemaster.

    Frankly, after doing this for over 2.5 years (tracking each of -STABLE
    and -CURRENT on a daily basis, missing a total of maybe a dozen days in
    that time for -STABLE; perhaps twice that for -CURRENT), I find it
    rather simple and straightforward. I would be hard-pressed to come up
    with a reason for wanting to find a different approach. (My build
    machine -- which is presently powered off -- has built something along
    the order of the 875th iteration of its -STABLE kernel since /usr/obj
    was last cleared. The laptop's numbers are considerably smaller, as I
    needed to replace the disk drive a few months ago. And -CURRENT tends
    to need clearing /usr/obj a bit more often than -STABLE does. :-})

    Peace,
    david 

    -- 
David H. Wolfskill				david@catwhisker.org
I do not "unsubscribe" from email "services" to which I have not explicitly
subscribed.  Rather, I block spammers' access to SMTP servers I control,
and encourage others who are in a position to do so to do likewise.
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscribe@freebsd.org"
  • Next message: Ruslan Ermilov: "Re: ng_bridge(4) has an easily exploitable memory leak"

    Relevant Pages