• cvs update question

    From Dumas Walker@VERT/CAPCITY2 to Digital Man on Saturday, December 21, 2019 17:50:52
    Good morning,
    A couple of weeks ago I was asking about how to get cvs update to overwrite files it thinks were changed on this end (but either were not or were done by accident <grin>). You mentioned using the -C option on the command line. I added that, and double checked the man page. That sure sounds like what I want.

    However, I am still seeing messages like the one here:

    cvs update: move away `exec/load/key_defs.js'; it is in the way
    C exec/load/key_defs.js

    I am assuming that the first message is now only a warning and the second one tells me it really did overwrite the file. Is that correct? The reason I ask is that the date and time stamp is the same in my exec backup tarball for this file as it is in /sbbs/exec after running the update (sept 23). Makes me wonder
    if it is really overwriting the files like I expect it to.

    Thanks!

    ---
    Synchronet CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP
  • From Digital Man@VERT to Dumas Walker on Saturday, December 21, 2019 18:58:04
    Re: cvs update question
    By: Dumas Walker to Digital Man on Sat Dec 21 2019 09:50 am

    Good morning,
    A couple of weeks ago I was asking about how to get cvs update to overwrite files it thinks were changed on this end (but either were not or were done by accident <grin>). You mentioned using the -C option on the command line. I added that, and double checked the man page. That sure sounds like what I want.

    However, I am still seeing messages like the one here:

    cvs update: move away `exec/load/key_defs.js'; it is in the way
    C exec/load/key_defs.js

    That means the file is on disk, but it wasn't put there via CVS to begin with (maybe extracted from a zip or tgz file instead?).

    I am assuming that the first message is now only a warning and the second one tells me it really did overwrite the file. Is that correct? The reason I ask is that the date and time stamp is the same in my exec backup tarball for this file as it is in /sbbs/exec after running the update (sept 23). Makes me wonder
    if it is really overwriting the files like I expect it to.

    No, you'll need to delete the file. If you have custom changes in your exec or exec/load directory, probably best to just rename that directory and get a fresh copy via CVS. Then in the future a "cvs update" should be no problem should want to perform one.

    digital man

    Synchronet/BBS Terminology Definition #9:
    BSO = Binkley Style Outbound
    Norco, CA WX: 65.6F, 35.0% humidity, 0 mph SE wind, 0.00 inches rain/24hrs

    ---
    Synchronet Vertrauen Home of Synchronet [vert/cvs/bbs].synchro.net
  • From Dumas Walker@VERT/CAPCITY2 to DIGITAL MAN on Monday, December 23, 2019 00:21:00
    That means the file is on disk, but it wasn't put there via CVS to begin with (
    aybe extracted from a zip or tgz file instead?).

    Unless they are left-over from my windows install (> 10 years ago since I switched), they did indeed come from CVS. I have changed some files but
    these are always ones I did not change and would not even know what they
    were for.

    No, you'll need to delete the file. If you have custom changes in your exec or >xec/load directory, probably best to just rename that directory and get a fresh
    copy via CVS. Then in the future a "cvs update" should be no problem should wan
    to perform one.

    Sounds like I need to do that even when I don't have any custom changes. I
    am not convinced that cvs (or git, for that matter) are not buggy. Unless
    it is an ASC, ANS, INI, or some file that SCFG & it's companions would
    change, I have very likely not touched it.


    * SLMR 2.1a * Working hard to become roadkill on the Infobahn.

    ---
    Synchronet CAPCITY2 * capcity2.synchro.net * Telnet/SSH:2022/Rlogin/HTTP