[volunteers] Fwd: [web-team] Linode Support Ticket 5649987 - Critical Xen Maintenance / Reboot Schedule

Rick Moen rick at linuxmafia.com
Mon May 2 03:19:05 PDT 2016


Quoting Daniel Gimpelevich (daniel at gimpelevich.san-francisco.ca.us):

> I didn't feel comfortable simply deleting Jesse's talk without first
> checking it into version control. I first examined the diff this would
> constitute, which seemed OK. Afterward, I forewent checking it in again,
> because I saw no need to preserve a simple "TBA" when it was expected to
> change within a day.

Yeah, well, no problem.  I was just being compulsive.

> >    What files in the Web tree are untracked?
> > 
> > rick at gruyere:~/www$ svn status | grep ^A
> 
> This is incorrect. Untracked files are marked with ? rather than A.
> These are files which are already tracked but are still waiting for
> initial check-in.

Above did not claim that A indicates untracked.  I just said that I was
aiming to find untracked files, which I did further along.

Please understand that these summaries are not carefully edited in any
way.  It's more a running commentary as I work something through.  Going
back and giving it a top-to-bottom and bottom-to-top edit would add
unacceptably to time required.


> > rick at gruyere:~/www$ sudo svn ci -m 'Check in stv directory files' stv/restaurant-200407.votedef stv/restaurant.php stv/restaurant-200408.votedef stv/prez2001.votes stv/restaurant.votedef stv/svlug-pres-term-2004-results.php stv/svlug-pres-term-2004.votes stv/restaurant-200407.desc stv/prez2001a.desc-tmp stv/prez2001.desc stv/restaurant-200407-results.php stv/restaurant-200408-results.php stv/prez2001.php stv/svlug-pres-term-2004-alt.votes stv/svlug-pres-term-2004.desc stv/restaurant-results.php
> > stv/prez2001.votedef stv/restaurant-200407.votes stv/restaurant-200408.votes stv/svlug-pres-term-2004.php stv/restaurant.votes stv/svlug-pres-term-2004.votedef stv/svlug-pres-term-2004-alt.desc stv/prez2001b.desc-tmp stv/restaurant-200408.desc stv/svlug-pres-term-2004-alt.php stv/svlug-pres-term-2004-alt.votedef stv/prez2001-results.php stv/restaurant-200407.php stv/restaurant-200408.php stv/Xrestaurant-200408.votes stv
> 
> Specifying all those files is redundant, because the specifying the stv
> directory at the end like that is recursive.

Yes, I know that _now_.  I didn't know that _then_.

What you don't know is that I first tried the same checkin command
without the 'svn' (dir) at the end, and got a bizarre check-in error
complaining that the dir itself was not under version control.  So, I
tried adding the dir, and got a bizarre error objecting that the svn dir
_is_ already under version control.  So, I recalled the long command and
put 'svn' at the end, and suddenly the files were all accepted.

I don't start out these things with an expert grasp on pretty much any
part of it, with a few honourable exceptions.  Instead, I just hammer
indelicately until the job's done.  So, frequently not pretty -- and I
don't clean it up before sending.

> No, 644 would reintroduce a need for sudo when touching these files. I
> have now fixed this.

Sure, 664's much better for that use-case.  I hadn't thought that
through, obviously.  I just thought 'weird, world read permission's
missing', and did the quick and dirty fix of the observed problem
without thinking about the best rights mask.

If you have time, you might put something about 664 being a desired set
of permissions for files put in the system HTML tree into the site-docs
somewhere.  Probably somebody put the presentation files in there with
root authority and didn't bother to check rights.  Quite possibly me.

Tbe reason I'm not offering to document it myself is that I'm dead tired
and need to get up early, too.

> The site-docs consistently use the traditional SCM terms "check-in" and
> "check-out" rather than more newfangled terms such as "commit." In
> keeping with this, I referred to the "svn up" command as a "check-out."
> It occurred to me right afterward that this may be confused with the
> "svn co" command, so I hurriedly logged in to see for myself that that
> command was not issued instead. I was quite relieved.

Quite.  ;->  Fortunately, I'm really careful.

> This was NOT needed before, so I am a little worried. Previously,
> check-ins appeared in the log right away.

Yeah, dunno.

> And to add insult to injury, when I did the check-out, deleted files
> that were still tracked by version control got auto-restored without
> asking for confirmation:
> 
> danielg4 at gruyere:~/www$ svn up
> Restored 'events/hacksoc.shtml.bak'
> Restored 'prev/2008may/SVLUG0904.odp'
> Restored 'prev/2008may/TurtleArt.odp'
> Restored 'phpinfo.php'
> At revision 340.

Er, yeah, that's pretty unfortunate.

No idea, and no more energy to investigate, at this very late hour.




More information about the volunteers mailing list