Re: pthreads imported to the Sourceforge CVS

[Igor Khavkine <i_khavki@alcor.concordia.ca>]

Marcus Brinkmann wrote:
> 
> On Tue, Jun 12, 2001 at 08:56:37AM -0400, Igor Khavkine wrote:
> > On Tue, Jun 12, 2001 at 08:43:56AM +0200, Niels M?ller wrote:
> > > Igor Khavkine <i_khavki@alcor.concordia.ca> writes:
> > >
> > > > and all the files ended up in pthread/libc/libc/ instead of
> > > > pthreads/libc. So can someone with a clue take a look at this mess
> > > > and try and fix it?
> > >
> > > The bbest way to fix that kind of mistake is to simply move the
> > > directories around in the repository. Do you have shell-access at
> > > sourceforge? Otherwise, you'll need help from someone who has.
> >
> > That's probably the best idea. I have shell access to sourceforge
> > since I have an account there. But where can I access the CVS
> > directories directly? I couldn't find them on the shell server,
> > and cvs.sourceforge.net does not accept ssh connections.
> 
> I don't think you are allowed to.  You'd have to ask the sf admins to clean
> out the module entirely, and start from scratch.  Mmh.  How about just
> killing the libc tree and do it correctly the second time?  I don't think
> some attic is harmful, if this is not supposed to be the ultimate place for
> it (wihch it shouldn't).
> 
> Thanks,
> Marcus

Actually the problem has been fixed. The SF CVS admins cleaned up the
mess
and I did a clean import of the source tree and this time it worked. Now
my first goal is achived and everyone has easy access to the source.

As for killing the libc tree, I'm not against changing the structure of
the
code. Actually it would be a good idea because the libc structure is
suitable
for something that is portable to many platforms/architectures. But this
this
pthread library is Hurd specific.

I'll try to come up with a new directory hierarchy which will be simpler
then the current one. I just need to know what kind of portability
criteria
are we aiming for. For example if it's only going to run on i386-gnumach
then it's pointless to introduce a threading backend abstraction.

Igor