[Monotone-devel] somewhat incoherent debate over CVS limitations, with a feature request buried inside

[Zack Weinberg]

Appended to this message is a rather long argument about whether or
not expect should be removed from the sources.redhat.com 'src' CVS
repository.  But what it's really about is a limitation in CVS - if
you have one big repository with everything in it, you can only
subdivide it with 'modules', which don't really work.  Some of the
problems are evident in the argument, others are not so obvious (for
instance, modules can only be defined globally, individual repo users
can't make up their own.)

I'm not feeling coherent enough to design out how I think this stuff
*ought* to work, but I'm hoping y'all have clever ideas.

zw

<lxo> I really fail to see the point of actually removing a working copy of 
software just for the sake of it.  it's not even like it's going to save space 
in the CVS server.  but heck, if you want that so badly, as far as I'm 
concerned, go for it.  but please check with cgf first
<lxo> remember that src is a shared repo, and Cygwin is one of the projects 
hosted in it, so if Cygwin does care about it, it must stay
<bje> If you are happy for me to submit top-level changes to ignore and not 
build src/expect, then I will agree with you
<bje> However that is not the case.
<bje> I will consult with cgf.
<lxo> the point is people don't have to check it out
<lxo> removing it from the top level would be even worse, because it would 
remove the option for people to add it back
<lxo> and I'd definitely be in the way of such a change
<pinskia> this all came up, but the point of removing it too make sure that 
there are not two versions of the thing and nobody knows which one to use
<lxo> use whatever works best for you?  isn't this one of the main points of 
free software?
<lxo> and then, heck, this is the #gcc channel, why are we even talking about 
removing expect from some CVS repository that is not the GCC repository here?
<zwol> the point is some of us are sick of getting burnt by incompatible 
tcl/expect/dejagnu that accidentally got checked out when we didn't wnat them
<lxo> then do not check it out!
<pinskia> uber
<lxo> do not check it out!
<lxo> which module of uberbaum gets it?
<pinskia> src
<lxo> well, yeah, src gets you the entire repository.  what did you, erhm, 
expect? :-)
<zwol> cvs update gives you a choice of checking every last damn thing out (-d) 
or possibly not picking up updates you wanted (no -d)
<lxo> the only modules that explicitly bring in expect are dejagnu, 
gdb+dejagnu, sid-support and newlib+dejagnu.  it all makes sense to me
<zwol> modules, schmodules
<echristo> zwol: i just use cvs checkout for updating.
* pinskia  does not checkout using modules as it failed for me once in gdb world
<zwol> yeah, that works great as long as you only have one tree, and you don't 
care what its root directory name is, and you only ever use one CVS server so 
you can set CVSROOT 
<lxo> then use a better version of cvs?  removing expect because of this 
problem feels a lot like barking up a building thinking it's a tree
<lxo> :-)
<zwol> WHAT better version of CVS?!
<lxo> that was for pinskia, btw
<pinskia> 1.11.1p1
<lxo> zwol, as for the problems you mention, they're all easy to work around, 
worst case it may require you to rearrange your source trees a little bit
<lxo> removing expect is fixing the wrong problem
<zwol> nuh uh.
<pinskia> the other issue is expect in src is not updated any more
<bje> lxo: funny, you're the only one who feels this way :-)
<lxo> pinskia, having no clue on what problem you ran into, and what you used 
to build this version of cvs, it's impossible to tell whether something else 
could fix it
<pinskia> lxo: it is a stock redhat install
<lxo> what's redhat anyway? :-)
<pinskia> 9.0
<lxo> there isn't any such thing
<lxo> maybe you mean the ancient Red Hat Linux 9?
<pinskia> yep
<zwol> (i'd be willing to put up with expect in src CVS *if and only if* that, 
*and* tcl, *and* tk, were kept in lockstep with upstream
<zwol> )
<lxo> the one that was EOLed months ago?
<bje> zwol: Heh, good luck
<lxo> and you want to remove expect because it's just a few releases old?
<pinskia> lxo: so, it is still works
<lxo> wow, nice
<pinskia> heh
<zwol> (and when i say "in lockstep" i mean "automated daily rsync")
<lxo> zwol, it's a shared repo.  Cygwin uses that repo.  it uses whatever 
version of expect it wants there.  no other project but dejagnu needs it
<pinskia> dejagnu should not be in src also
<bje> pinskia: I hear you.
* zwol  is of the opinion that src should be broken up, actually
<lxo> what power do you think to set rules over part of a repository that's 
controlled by a different project, a repository that's not even the one used by 
GCC
<pinskia> I thought bje is part of the other project :)
<lxo> you want src to be broken up but then argue that the problem with expect 
is uberbaum, that happens to be the merge of src with gcc.  how is that 
consistent?
<zwol> It causes me headaches on a fairly regular basis.  Therefore I have the 
right to bitch about it.
<echristo> heh
<zwol> I don't claim to know what the correct solution is.
<bje> lxo: It's easy to feel justified when you're the one willing to make 
things better and every one else is happy to throw things at you from the 
sidelines, but not do the work themselves.
<echristo> personally i hate merging sources. i'll all in favor of having a 
single repo
<lxo> /echo echristo
<zwol> (if I were doing repo layout, probably I'd put gcc+gdb+binutils together 
in one CVS repo, and *nothing else*)
<echristo> newlib
<zwol> no
<zwol> no newlib, no sim either.
<lxo> because you don't care about cross tools?  and cygwin?
<lxo> sim is part of gdb
<echristo> screw you monkey boy :)
<zwol> i know. it shouldn't be.
<bje> lxo: OK, screw it.  I give up.  Let expect rot.
<zwol> (that has also caused me hours of lost effort in the past)
<lxo> you got a long way to get things the way you want.  and I'll do my best 
to make sure you fail, promise :-)
<pinskia> really sim should be in its own project
* bje  retires hurt
<echristo> heh.
<lxo> bje, no offense intended.  I still fail to see the point.  and what I 
said was that you should clear with cgf before removing it.
<pinskia> I would assume by now cgf would have read the mailing list
<echristo> actually, i don't really see a need for dejagnu and expect since 
those aren't needed for anything but the host.
<zwol> there's a meta-problem here, which is that people who are not helping 
tend to jump on people who are helping.
<pinskia> of both gcc, gdb and others
<lxo> he did.  and said Cygwin used it
<zwol> not assigning any people in this conversation to either category
<pinskia> but really cygwin should just use the upstream version
<lxo> when they do, we might remove expect from src, but even then, I wouldn't 
see the point of the gratuitous removal.  it doesn't save anything, it doens't 
fix any problem, and it inconveniences some.
<pinskia> it saves time for me when updating
<lxo> do not check expect out
<lxo> if you don't want it
<zwol> full circle.
<lxo> exactly
<echristo> *nod*
<pinskia> around it comes when I check out src
<zwol> i claim it is *impossible* to make CVS behave the way you claim it can 
be made to behave
<lxo> what was the argument against not checking it out again?
<lxo> zwol, how come it does for me?
<pinskia> the modules are not setup the way I need them to be
<zwol> you are probably not using cvs update -d, which means you are risking 
inconsistent checkouts
<echristo> the reason i check out dejagnu at all is because i have hacks to the 
sources that i don't have in my distro. and i hate building software i don't 
have to.
<lxo> use check out with the modules you want, or use cvs update -d */ in 
there, so you won't get expect checked out
<echristo> zwol: use cvs co
<lxo> and update -l for the top level
<lxo> update -d is somewhat incompatible with modules.  update -d will get you 
absolutely everything, even stuff that isn't in modules you checked out
<pinskia> what happens if a new toplevel directory comes about
<lxo> so use checkout module, or you get too much
<lxo> checkout module will get the new toplevel directory
<zwol> cvs co requires that (a) i issue the command in the parent of the 
checkedout tree, where there is no CVS directory to tell it where to find the 
server, and (b) requires that i not rename the directory containing the 
checkedout tree afterward.  neither is acceptable.
<lxo> and then you won't even have to use -d
<pinskia> the last time I tried that I got screwed
<echristo> zwol: b) is not true.
<echristo> i do this all the time.
<lxo> zwol, I said you might have to rearrange your source tree a little bit.  
naming the top level tree is one such detail
<echristo> a) is true. i usually cvsroot my most checked out cvs server
<lxo> as for not having a CVS directory to tell, just have a script in the CVS 
directory that does what you want, and run that
<zwol> echristo: how do you make it not check out the entire tree again under 
the name it wants?
<lxo> and if you use checkout to begin with, then renamed the directory, *you* 
did the rename.  why?
<lxo> if it breaks stuff
<pinskia> so ...
<zwol> so that I can have more than one working tree at once. duh.
<lxo> why not let it have the name it chose at first?
<lxo> ever heard of multiple directories?
<lxo> duh
<zwol> i'm sorry, the only solution i'm interested in is a fixed cvs update -d 
that honors the module selection on the original checkout.
<lxo> and soft links, for that matter, if you care so much about being able to 
access the tree with a particular name
<pinskia> I actually like the idea of being able to renaming the directories 
and not breaking
<lxo> so again you're barking up the wrong tree.  your issue is with cvs, not 
expect
<echristo> zwol: i have gcc-mips gcc-ppc gcc and such. i cd into, say, gcc-mips 
and then cvs co what i want
<pinskia> but expect should never gone in src in the first place :)
<zwol> my issue is with cvs, sure, but cvs ain't getting fixed
<lxo> it is part of cygwin, and cygwin uses the src repo
<echristo> pinskia: you weren't around in the olden days.
<lxo> it's a shared repo, live with it
<pinskia> but why is bash not there?
<lxo> I'm telling the way you can get it to work, but it looks like you just 
don't want to do it
<lxo> because not all of cygwin is in src
<pinskia> so why is expect still there then?
<lxo> in the case of expect, it was already there, because of dejagnu, so it 
didn't make sense to duplicate it elsewhere
<pinskia> but dejagnu has been move so expect should also
<lxo> how does that follow?
<lxo> cygwin still uses it
<lxo> it *could* choose to move, it doesn't have to
--> victorlei (address@hidden) has joined #gcc
<pinskia> for the same reason why bash is not in src, it is not needed there 
anymore
<pinskia> if expect was being maintained in src I would not have a problem with 
it being in there
<lxo> holy Christ.  why do you care?
<lxo> why would you care if I chose to add package foo to src?
<lxo> just do not check it out!
<zwol> lxo: you're not allowed to say that anymore unless you patch cvs so 
update -d honors the original module selection, 'k?
<lxo> nope
<zwol> basically this is an argument over who has to change their work habits
<lxo> I told you how to overcome this limitation of cvs already
<zwol> and neither side is willing to budge
<zwol> so we're fucked.
<lxo> you're the one who doesn't want to adjust your habits
<pinskia> huh?
<lxo> use check out module
<lxo> do not rename the checked out directory
<lxo> everything works
<pinskia> you said that cygwin uses expect but so you are saying cygwin should 
not adjust
<zwol> none of your suggestions are compatible with my work environment.  live 
with it.
<lxo> it doesn't have to, yes
<lxo> it's still Cygwin's CVS repo
<lxo> zwol, I'm sorry for you.  forcing a separate CVS repo to change because 
you made a wrong choice doesn't sound fair
<pinskia> but only for the main utils: newlib, gdb, binutils but not gcc or
<pinskia> bash
<zwol> who said i was forcing anything? i'm just complaining.
<lxo> if everyone were to force their view of what the repository should 
contain, how many different, partially-duplicated repositories would we need?
<lxo> cvs can do what you want, provided that you follow certain procedures
<lxo> you don't follow these procedures, and this gets you results you don't 
want
<zwol> I *can't* follow those procedures.
<pinskia> the whole point is that we already have a partially-duplicated repo
<lxo> pinskia, what are the main utils?
<pinskia> utils meaning projects
<lxo> yeah, what are they?
<pinskia>  newlib, gdb, binutils, winsup
<lxo> I disagree with zwol's notion that sim, newlib and winsup should be out
<lxo> and you apparently disagree with him as well
<lxo> zwol, it appears to me that you have to make some adjustments if you 
really don't want expect in your source trees
<pinskia> not really, I just said that this cygwin's cvs repo should contain 
them or a way to get them all at once like uber
<lxo> sure removing expect is one such alternative, but what's next?  remove 
something else because it doesn't fit in your work environment?
<pinskia> tcl
<zwol> Seriously, make update -d honor modules and i no longer have a problem.
<echristo> heck, lots of people no longer have problems at that point.
<lxo> why should I?  it works for me.
<echristo> i never understood that
<lxo> you're the one with the cvs issue.  so either follow a different 
procedure to get it to work for you, or fix it such that it works in your 
environment