Thread: Re: [Plib-devel] PLIB developers needed. (Page 2)
Brought to you by:
sjbaker
Menu
▾
▴
plib-devel
|
From: Steve B. <sjb...@ai...> - 2000-08-21 23:30:55
|
Christian Mayer wrote:
> > It certainly does use clip-texture - that's why they wrote that particular
> > demo.
>
> Sorry, but what's the clip-texture really doing?
Clip texture is lots of things - but essentially it allows you to have
a 'virtual' texture map that is *MASSIVE* - perhaps 1,000,000 x 1,000,000
texels. Since that's impossibly large, you are allowed to write into just
some sections at the highest MIPmap level - and others at lower levels -
and where there are gaps it can fill in.
Urgh - that's a terrible explanation - but essentially, it allows you
much more freedom in paging texture from disk efficiently.
The only 'gotcha' is that only hideously expensive ONYX'en have the
hardware to make it truly work.
> But it's been still very impressive (esp. at a time where nobody would
> expect 3d accelleration for consumer PCs)
It doesn't run on PC's (AFAIK) - or at least if it does, they found a way
to cram it all in without cliptexture (which is certainly possible).
> > They had a version where you zoomed in past the mountain and onto a
> > Nintendo-64 (which was developed by SGI) - through the case and down
> > into the 'Reality Chip'.
>
> Yup, that's the demo I saw. SGI also had a Nintendo-64 prototype at
> their booth running SuperMario 64.
Exactly. They actually offered me a job on the N64 design team - it
would have been a blast - but their pay scales (whilst MUCH better than
I was earning at the time in actual $$$) didn't come close to what I
was earning when you considered the cost of living in Silicon Valley
versus Texas.
:-(
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Gil C. <g.c...@ca...> - 2000-08-21 23:57:36
|
At 06:35 PM 8/21/00 -0500, you wrote: >Christian Mayer wrote: > > > > It certainly does use clip-texture - that's why they wrote that > particular > > > demo. > > > > Sorry, but what's the clip-texture really doing? > >Clip texture is lots of things - but essentially it allows you to have >a 'virtual' texture map that is *MASSIVE* - perhaps 1,000,000 x 1,000,000 >texels. Since that's impossibly large, you are allowed to write into just >some sections at the highest MIPmap level - and others at lower levels - >and where there are gaps it can fill in. > >Urgh - that's a terrible explanation - but essentially, it allows you >much more freedom in paging texture from disk efficiently. To get it from SGI themselves: "IRIS Performer on InfiniteReality® allows you to create textures that are much bigger than will fit in texture memory and even in system memory, so that you can fit your entire world in a single texture. IRIS Performer will also manage all of the texture loading for you from disk to system memory and then to texture memory, based on your current position in the database. IRIS Performer provides for virtual memory for very large Mip-mapped textures by only storing potentially visible texels in system and texture memory. Efficient management of texture memory is made possible by special capabilities of the InfiniteReality texturing hardware. This general technique is called clipmapping and is the subject of the rest of this paper" The paper which they're referring to is at http://www.sgi.com/software/performer/presentations/clipmap_intro.pdf Rgds, Gil |
|
From: Steve B. <sjb...@ai...> - 2000-08-22 00:29:28
|
Gil Carter wrote: > To get it from SGI themselves: > > "IRIS Performer on InfiniteReality® allows you to create textures that are > much bigger than will fit in texture memory and even in system memory, so > that you can fit your entire world in a single texture. IRIS Performer will > also manage all of the texture loading for you from disk to system memory > and then to texture memory, based on your current position in the database. > IRIS Performer provides for virtual memory for very large Mip-mapped > textures by only storing potentially visible texels in system and texture > memory. Efficient management of texture memory is made possible by special > capabilities of the InfiniteReality texturing hardware. This general > technique is called clipmapping and is the subject of the rest of this paper" > > The paper which they're referring to is at > http://www.sgi.com/software/performer/presentations/clipmap_intro.pdf This is about how Performer *uses* Clipmapping - the underlying OpenGL extension doesn't do file I/O and such like - that's purely a Performer thing. -- Steve Baker HomeEmail: <sjb...@ai...> WorkEmail: <sj...@li...> HomePage : http://web2.airmail.net/sjbaker1 Projects : http://plib.sourceforge.net http://tuxaqfh.sourceforge.net http://tuxkart.sourceforge.net http://prettypoly.sourceforge.net |
|
From: Steve B. <sjb...@ai...> - 2000-08-12 19:11:16
|
Christian Mayer wrote:
> > It didn't even get through the ul.h header. There was no other code
> > involved apart from standard UNIX headers prior to that point. Also,
> > the program compiles just fine under Linux - so there isn't
> > anything wrong with my code.
>
> Just that it compiles under one system doesn't say that there's nothing
> wrong with it.
You misunderstand - none of my code has entered the compiler at that point.
The source file says something like:
#include <stdio.h>
#include <plib/ul.h>
...more stuff...
..and the compiler barfs inside plib/ul.h when I remove the const from
within the function definitions....
int getWhatever () const { return whatever ; }
^^^^^
here
...it compiles and runs just fine.
> I don't know what causes it (I don't know any of the affected code). So
> it might be your code or it might be the code in the ul.h or perhaps
> even something totally different. I don't know it. So I'm not saying
> who's guilty.
It's not a matter of guilt. Putting a 'const' right there is OK in
sufficiently modern C++ compilers - it fails in older ones though - so
we can't use that construct and remain 'sufficiently' portable.
> > We are looking at a use of 'const' that is in a more recent C++ spec
> > than IRIX supports (this is just like the declaration-inside-a-for-loop
> > issue for MSVC).
> >
> > If we want our code to be portable, we have to forgo some of the
> > fancier features of C++ in order to get through the lowest-common-denominator
> > of all C++ compilers.
>
> I allways thought that const was one of the most basic C++ features.
It is - but not *there*.
const float pi = 3.14159 ; -- OK
int func ( const int &x ) ; -- OK
int getWhatever () const { return whatever; } -- NOT OK
> But anyway, do SG and SSG brake with that compiler?
This program only happened to use UL...but SG and SSG don't (AFAIK)
use const in *that* context.
> If the answer is no,
> that is compiler supporting costs. SG *is* const correct and at least
> half of SSG (IIRC).
Well - not exactly. The number of places where the keyword 'const' can
be stuck has grown steadily over the life of C++ - and some of the later
ones simply aren't universally supported.
> No matter where it compiles. As soon as it doesn't compile on one
> (reasonable) system make it intolerable.
Exactly...unfortunately.
> But you can't cry and say 'ban all consts' just because you trip over
> one that doesn't work - w/o really knowing if it's the const that causes
> the problem or if its breaking the compiler just because the real
> problem (probably a forgotten const) stays unnoticed.
I don't really want to ban them all - just that particular usage (and
any others that we might find will break compilation on important
platforms).
One might argue about what platforms are important enough to warrent
dumping language features that are useful. However, IRIX is defined as
'important' because (selfishly) "PLIB is mine and I use IRIX"
:-)
If a similar question came up about compiling for (say) AmigaOS - the
answer *might* be different!
Personally, I think a minimal supportable OS set for PLIB is:
Windoze (all versions NT/95 and later (except possibly, Wince) - using
at least MSVC++, Borland and Cygwin)
Linux (2.0.0 and later)
BeOS (?? versions)
BSD (Including NetBSD, FreeBSD, etc)
MacOS (?? versions)
IRIX (6.0 and later)
Solaris (?? versions)
...I'd consider supporting SCO Unix and HPUX also...but if we had to make
significant language restrictions to make that work, I'd want to think twice
about *that* decision.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Gil C. <g.c...@ca...> - 2000-08-10 06:13:54
|
>Linux people: Please don't do this:
>
> for ( int i = 0 ; i < 10 ; i++ ) whatever ;
> for ( int i = 0 ; i < 20 ; i++ ) whatever ;
>
>(Although it's perfectly legal C++ - MSVC barfs on it - I forget
> about this *every* time - sorry Windoze dudes!)
But to credit Leath Muller (I think), this will fix that problem:
{ for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
{ for ( int i = 0 ; i < 20 ; i++ ) whatever ; }
But it's daggy and isn't something you'd write given a choice :-)
Gil
|
|
From: Sam S. <sa...@sp...> - 2000-08-10 13:03:10
|
----- Original Message -----
From: "Gil Carter" <g.c...@ca...>
To: <pli...@li...>
Sent: Thursday, August 10, 2000 7:13 AM
Subject: Re: [Plib-devel] PLIB developers needed.
>
> >Linux people: Please don't do this:
> >
> > for ( int i = 0 ; i < 10 ; i++ ) whatever ;
> > for ( int i = 0 ; i < 20 ; i++ ) whatever ;
> >
> >(Although it's perfectly legal C++ - MSVC barfs on it - I forget
> > about this *every* time - sorry Windoze dudes!)
>
> But to credit Leath Muller (I think), this will fix that problem:
>
> { for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
> { for ( int i = 0 ; i < 20 ; i++ ) whatever ; }
>
> But it's daggy and isn't something you'd write given a choice :-)
I believe the revised ANSI C++ scoping rules now forbid declaration of variables in a for statement, completely. But this is fairly
recent, so different compilers are still tolerating it in different ways.
The scoping for this sort of declaration was always cloudy at best, so it's probably for the best.
Bottom line - don't do it.
Sam
|
|
From: Steve B. <sjb...@ai...> - 2000-08-11 04:56:04
|
Sam Stickland wrote:
>
> I believe the revised ANSI C++ scoping rules now forbid declaration of variables in a for statement, completely. But this is fairly
> recent, so different compilers are still tolerating it in different ways.
*WHAT* ??!?
That's insane.
> The scoping for this sort of declaration was always cloudy at best, so it's probably for the best.
Not really. In the first C++ spec, it said (quite clearly) that the scope was as
if you'd declared the variable immediately before the 'for' loop. It was realised
by everyone that this was a bad decision - and Bjarne said so in the 'ARM' (Annotated
Reference Manual) - but he decided not to wreck all those existing programs by
changing the language to correct his error.
When ANSI first looked at the problem, they decided that it was better to have the
language "right" - even if that did cause some initial pain. The pain was dealt
with by *everyone* except Microsoft...
And now you are telling me that they are *both* wrecking the language *and* pissing
off a million programmers?
Geeze. That's a *terrible* decision.
> Bottom line - don't do it.
Well, that was always the bottom line for portable code...but I had hopes that
one day Microsoft would either *DIE* or fix their fscking compiler and we could
all get on with life.
Ack!
They should really have left the C++ spec as it was rather than keep tinkering
with it. IMHO, just about everything that's happened to C++ since Bjarnes'
first implementation has been a BAD mistake.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: <Va...@t-...> - 2000-08-10 20:39:55
|
Gil Carter wrote:
>
> >Linux people: Please don't do this:
> >
> > for ( int i = 0 ; i < 10 ; i++ ) whatever ;
> > for ( int i = 0 ; i < 20 ; i++ ) whatever ;
> >
> >(Although it's perfectly legal C++ - MSVC barfs on it - I forget
> > about this *every* time - sorry Windoze dudes!)
>
> But to credit Leath Muller (I think), this will fix that problem:
>
> { for ( int i = 0 ; i < 10 ; i++ ) whatever ; }
> { for ( int i = 0 ; i < 20 ; i++ ) whatever ; }
>
> But it's daggy and isn't something you'd write given a choice :-)
Yup it fixes it. That's because in MSVC and in ANSI the i have a
different scope.
CU,
Christian
|
|
From: Paul B. <pbl...@di...> - 2000-08-10 06:32:15
|
>From: Dave McClurg [mailto:Dav...@dy...] >Subject: RE: [Plib-devel] PLIB developers needed. > > for private functions, use all_lower_case unless they would > pollute the name space in which case you should use _xxMixedCase > (note the leading underscore). if a variable pollutes the name > space, use _xxMixedCase. Note that this technically goes against the portability aspect of PLIB as identifiers in the global and std:: namespaces starting with '_' and '__' are reserved for the implementation in ANSI C++. http://oakroadsystems.com/tech/cppredef.htm#Groups I know it is used by alot of code and I do it too, but I thought it should at least be known. I get killed by it everytime I write a header file: #ifndef __Foo_h__ #define __Foo_h__ #endif is discouraged (because the two leading underscores) as the implementation (compiler) may legally predefine those values. Paul |
|
From: Steve B. <sjb...@ai...> - 2000-08-11 04:55:54
|
Paul Bleisch wrote:
>
> >From: Dave McClurg [mailto:Dav...@dy...]
> >Subject: RE: [Plib-devel] PLIB developers needed.
> >
> > for private functions, use all_lower_case unless they would
> > pollute the name space in which case you should use _xxMixedCase
> > (note the leading underscore). if a variable pollutes the name
> > space, use _xxMixedCase.
>
> Note that this technically goes against the portability aspect
> of PLIB as identifiers in the global and std:: namespaces starting
> with '_' and '__' are reserved for the implementation in ANSI C++.
Yes - but the alternative isn't very pretty either.
> I know it is used by alot of code and I do it too, but I thought
> it should at least be known. I get killed by it everytime I
> write a header file:
>
> #ifndef __Foo_h__
> #define __Foo_h__
> #endif
Exactly.
...and in practice, it's very portable and saves a lot of other problems.
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 14:45:31
|
I've got several FAQs, but still haven't got things working. :-( I've got a version of ssh that *does* work. I can do ssh -l markus5 plib.sourceforge.com and I can login, etc. So far, so good. I've got a version of cvs that works for :pserver: and can anonymously checkout and update. I've configuring cvs to use :ext: and set the CVS_RSH variable to use ssh. It looks like cvs *is* using ssh rather than the internal :pserver: stuff. Again, so far, so good. I used cvs/ssh to checkout the files. Again, so far, so good. But, cvs still reports "needing write access to update repository" when trying to commit. ?wha? Well, a guy has to see his family sometime, so I quit. Something is still not right. After some sleep I've got a few ideas, but any suggestions are welcome. Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > > "Vallevand, Mark K" wrote: > > > > I'm supposed to have CVS write access to PLIB, but it doesn't > > work. > > Well, I've checked - and you certainly ARE on the write access list: > > markus5 - Mark > mcdave - Dave > sjbaker - Steve > sps196 - Sam > > There are at least 4 HOWTO/FAQ documents specifically for > Windoze users > somewhere on Sourceforge...erm....here: > > http://sfdocs.sourceforge.net/sfdocs/ > > -- > Steve Baker |
|
From: Wolfram K. <w_...@rz...> - 2000-08-10 16:22:35
|
You wrote: >But, cvs still reports "needing write access to update repository" >when trying to commit. I think you are bitten by the same feature I fought with some time ago. When you import a module anonymously, cvs somewhere remembers that these files belong to Mister anonymous. Checking out individual files doesn't change this. So, when you try to commit them, it doesn't work, since the "files are anonymous" and Mr anonymous has no write access rights. I hope the explanation is at least half-way correct, the end result is: Import the complete module plib into a new directory using ssh. Then you should be able to change the files and commit them back into CVS. >Regards. >Mark K Vallevand ma...@rs... Bye bye, Wolfram. |
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 16:16:58
|
I'm pretty sure I did this correctly. I'll check my scripts. I did checkout the changed files as 'markus5' after I checked out all of plib anonymously. Maybe there is some residue from the anonymous checkout getting in the way, even though I did check the files our again as 'markus5'. I'll save plib, start over, and checkout a completely new copy of plib as 'markus5'. Then, I'll copy the changed files from the saved plib into plib. I'll try committing after that. This *does* make sense in a way. But, I am sure that checking out the files a second time (after deleting them first) as 'markus5' did work. Then updating them and committing them as 'markus5' should work, too. But, it didn't. So, maybe the anonymous checkout is getting in the way. Also, there are some environment variables that need to be setup. Maybe I've got something mis-typed there. Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > -----Original Message----- > From: Norman Vine [mailto:nh...@ca...] > Sent: Thursday, August 10, 2000 10:57 AM > To: pli...@li... > Subject: RE: [Plib-devel] PLIB developers needed. > > > Mark K Vallevand writes: > > > >I'm supposed to have CVS write access to PLIB, but it doesn't > >work. > > > >Here is what I did: > >- anonymous checkout of all of plib; > >- verify that plib still works for me (it does); > >- checkout (as markus5, my sourceforge ID) the 3 files that > >are changing; > >- change the files; > >- commit (as markus5) the 3 files that changed. > > > >The commit says I don't have write access. > >Any ideas? > > Mark > > You wouldn't perchance be trying to update from a branch > where the ./cvs/root file reads as > :pserver:ano...@cv...:/cvsroot/plib > > would you ?? > > if so try changing it to read > ma...@cv...:/cvsroot/plib > > You can only update from a tree / branch checked out by a > 'known' user in a SSH CVS repository. > > This might not have been set correctly since you did the > initial checkout annonymously. > > Norman > > > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel > |
|
From: Sam S. <sa...@sp...> - 2000-08-10 16:35:36
|
----- Original Message ----- From: "Vallevand, Mark K" <Mar...@UN...> To: <pli...@li...> Sent: Thursday, August 10, 2000 5:16 PM Subject: RE: [Plib-devel] PLIB developers needed. > I'm pretty sure I did this correctly. I'll check my scripts. > I did checkout the changed files as 'markus5' after I checked > out all of plib anonymously. Maybe there is some residue from > the anonymous checkout getting in the way, even though I did > check the files our again as 'markus5'. Ah, I see.. No this won't work... CVS will look for a directory called CVS, and if it finds it it will use the contents of CVS/root to do the checkout - so it will still be anonymous@blah. It's actually a "feature" to stop you accidently mixing the contents of two different CVS stores. You check out plib into CVS-devel/plib with your plib user id. You change CVSROOT and then check out, say, Mesa into CVS-devel/mesa3d You go back to CVS-devel/plib and type cvs update. If it didn't use CVS/root as your CVSROOT it would attempt to update from the mesa cvs store. You'll have to check the whole of plib out as markus5 and then the commits will work. Sam |
|
From: Norman V. <nh...@ca...> - 2000-08-10 17:43:05
|
Sam Stickland writes: > >Ah, I see.. No this won't work... CVS will look for a >directory called CVS, and if it finds it it will use the >contents of CVS/root >to do the checkout - so it will still be anonymous@blah. It's >actually a "feature" to stop you accidently mixing the contents of >two different CVS stores. If you do not want to recheckout all the files and have python installed here is a little script that will change the local cvs/root files for you http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py Norman |
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 16:30:49
|
This must be it. Thanks. Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > You wrote: > > >But, cvs still reports "needing write access to update repository" > >when trying to commit. > > I think you are bitten by the same feature I fought with some time > ago. When you import a module anonymously, cvs somewhere > remembers that these files belong to Mister anonymous. > Checking out individual files doesn't change this. So, when > you try to commit them, it doesn't work, since the "files are > anonymous" and Mr anonymous has no write access rights. > > I hope the explanation is at least half-way correct, > the end result is: Import the complete module plib into a new > directory using ssh. Then you should be able to change the files and > commit them back into CVS. > > >Regards. > >Mark K Vallevand ma...@rs... > > Bye bye, > Wolfram. |
|
From: Dave M. <Dav...@dy...> - 2000-08-10 17:23:13
|
Steve wrote:
> I tried to compile PLIB on an SGI machine at work - and your
> 'const-ification' of the clock
> routine stopped it from compiling on the IRIX compiler.
>
> You had:
>
> class ulClock
> {
> ...
> public:
> ...
> int getSomething () const { return something ; }
> ...
> } ;
>
> The 'const' seemed to do *bad* things to the SGI compiler.
>
> Could you remind me what exactly a 'const' right there
> actually *does*?
>
> ...and then remove them anyway!
>
I use 'const' in only two ways:
1) const data -- const Type* foo ;
2) const method -- Type getSomething () const ;
#1 means you can't change what foo points to. You already use this heavily
in SG. #2 means that the class method getSomething cannot change its
instance. it is commonly used for inline 'query' methods. #1 and #2 are
often used together. for example, if you write a function like this:
void checkfoo ( const Type* foo )
{
return ( foo -> getSomething () == 42 ) ;
}
if getSomething() is not a 'const' method then you get a warning because it
thinks you are changing what foo points to. the alternative is casting away
the 'const' of foo ala ((Type*)foo) which is not as clear.
I really thought 'Type getSomething () const' was a very portable and
standard idiom. Could you check the SGI documentation on that? If needed,
I will remove the 'const' methods as you advise.
--Dave
|
|
From: Steve B. <sjb...@ai...> - 2000-08-11 04:56:11
|
> Dave McClurg wrote:
>
> Steve wrote:
> > I tried to compile PLIB on an SGI machine at work - and your
> > 'const-ification' of the clock
> > routine stopped it from compiling on the IRIX compiler.
> #1 means you can't change what foo points to. You already use this heavily in SG.
Sure - that makes sense.
> #2 means that the class method getSomething cannot change its instance.
Ah! I see.
> I really thought 'Type getSomething () const' was a very portable and standard
> idiom. Could you check the SGI documentation on that?
I don't have documentation that's *that* detailed. But the code flat-out
won't compile. Hard errors - not just warnings. Simply deleting the 'const'
was enough to make it compile.
> If needed, I will remove the 'const' methods as you advise.
'fraid so. I use PLIB on SGI's quite a bit these days - and it's
rather embarassing when my very own *portable* library won't compile
on the computer on my desk!
You may have wondered why I don't use 'const' a whole lot - maybe you
realise why! I loath and detest "creeping const" - where const's have
to be put in and taken out continually to get the program to compile.
AAARRRGGGHHHH! The few (very few) bugs they save you from are certainly
not worth the hassle. C (and hence C++) is a great language because it
DOESN'T treat the programmer like a small child. You are allowed to make
mistakes - and in exchange get to be all-powerful.
Like I said in my last post - C++ was a *great* language in the very
first release - everything added to it since then has been a downhill
slide.
C + classes + overloaded functions + virtual functions ... was
all I ever wanted!
The only addition that I'd make to the original C++ language would
be:
type *x ;
....
delete x ;
...should do an implicit "x=NULL;"
But I can live without it!
--
Steve Baker HomeEmail: <sjb...@ai...>
WorkEmail: <sj...@li...>
HomePage : http://web2.airmail.net/sjbaker1
Projects : http://plib.sourceforge.net
http://tuxaqfh.sourceforge.net
http://tuxkart.sourceforge.net
http://prettypoly.sourceforge.net
|
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 17:53:09
|
And the rub is "python installed." :-) Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > If you do not want to recheckout all the files and have > python installed > here is a little script that will change the local cvs/root > files for you > http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py > > Norman |
|
From: Norman V. <nh...@ca...> - 2000-08-10 18:11:12
|
> >And the rub is "python installed." :-) Tsk Tsk :-) Perl versions here http://www.red-bean.com/cvsutils/ |
|
From: Loring H. <ls...@cs...> - 2000-08-10 18:00:06
|
> And the rub is "python installed." :-) I'm unclear what the problem is. I have write access to a sourceforge project and I want to be able to switch between anonymous CVS and CVS writing. I want to use anonymous CVS when I'm updating my tree, but CVS writes when checking something into the tree. At the top level of the tree, I can do the following to update my tree: cvs -d:pserver:ano...@cv...:/cvsroot/quake update And the following to do writes (with CVS_RSH set to ssh): cvs -d...@cv...:/cvsroot/quake commit Once I do the write, I can do the former to reset CVS/Root to be the anonymous version. It's just that simple when your CVS tree isn't deep, but it gets more complicated when you have a deep hierarchy. If you are only operating from the root, you are fine with this scenario. If you are running cvs commands from other directories, you'd have to use the cvs update command in those directories to fix up CVS/Root Loring > > If you do not want to recheckout all the files and have > > python installed > > here is a little script that will change the local cvs/root > > files for you > > http://www.vso.cape.com/~nhv/files/python/cvs_chroot.py > > > > Norman |
|
From: Wolfram K. <w_...@rz...> - 2000-08-10 19:04:37
|
Loring wrote: >I have write access to a sourceforge project and I want to be able to switch >between anonymous CVS and CVS writing. But did you do the initial checkout anonymously? I think thats the point. >Loring Bye bye, Wolfram. |
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 18:21:09
|
Norman, you are a fountain of information. Perl. One of my favs. Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > -----Original Message----- > From: Norman Vine [mailto:nh...@ca...] > Sent: Thursday, August 10, 2000 1:11 PM > To: pli...@li... > Subject: RE: [Plib-devel] PLIB developers needed. > > > > > >And the rub is "python installed." :-) > > Tsk Tsk :-) > > Perl versions here > > http://www.red-bean.com/cvsutils/ > > _______________________________________________ > plib-devel mailing list > pli...@li... > http://lists.sourceforge.net/mailman/listinfo/plib-devel > |
|
From: Vallevand, M. K <Mar...@UN...> - 2000-08-10 18:50:59
|
This is almost what I did! The difference is that when I checked out the files again under my userid using cvs/ssh, I only checked out the three files that were being changed. And, I only committed the three files that were changed. Could this make a difference? If I commit *all* of plib, is cvs clever enough to only commit the files that are actually changed? Regards. Mark K Vallevand ma...@rs... Never try and teach a pig to sing: it's a waste of time, and it annoys the pig. > I'm unclear what the problem is. > > I have write access to a sourceforge project and I want to be > able to switch > between anonymous CVS and CVS writing. > > I want to use anonymous CVS when I'm updating my tree, but > CVS writes when > checking something into the tree. > > At the top level of the tree, I can do the following to > update my tree: > cvs > -d:pserver:ano...@cv...:/cvsroot/quake update > > And the following to do writes (with CVS_RSH set to ssh): > cvs -d...@cv...:/cvsroot/quake commit > > Once I do the write, I can do the former to reset CVS/Root to be the > anonymous version. It's just that simple when your CVS tree > isn't deep, but > it gets more complicated when you have a deep hierarchy. If > you are only > operating from the root, you are fine with this scenario. If you are > running cvs commands from other directories, you'd have to > use the cvs update > command in those directories to fix up CVS/Root > > Loring |
|
From: Loring H. <ls...@cs...> - 2000-08-10 21:37:13
|
> This is almost what I did! > The difference is that when I checked out the files again under > my userid using cvs/ssh, I only checked out the three files that > were being changed. And, I only committed the three files that > were changed. Could this make a difference? possibly - I usually commit and update by directory (cvs commit, not cvs commit file1 file file2 or cvs update, not cvs update file file2). > If I commit *all* of plib, is cvs clever enough to only commit the files > that are actually changed? Yes Loring |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X