From: David Doolin (doolin@cs.utk.edu)
Date: Tue Oct 03 2000 - 10:16:26 EDT
[]
>> cvs can be picky about such things, but it is very doable.
>> It helps (alot) to understand how ./CVS/Entries works.
>
> I think I understand pretty well how CVS work, I don't want
>to break CVS checkout of people especilly on the Gnome CVS base.
This is important enough to leave the repository alone!
>
> There is either:
> - create the new directory, move the files there, cvs delete
> an then cvs add in the new directory.
> => I don't want this option before a new major change to
> avoid loosing the CVS logs
> - simply move the ,v files on the server but I'm absolutely opposed
> to this since this will break all the client checkouts, it's
> bad behaviour
>
> I don't want to mess with the CVS repository now, there is of
>course things which could be done to not break existing checkouts and
>make that change at the CVS level, but people updating without -d
>could be in trouble.
Since everything works well enough as it is now, no need to hurry.
On the win32 side, since libxml does not depend on e.g., glib or lex,
porting really is not that difficult. Changes to the repository
structure fall under the "nice to have but not necessary" category.
>
>> >this structure automatically. I don't think I will change the CVs structure
>> >(and hence my enviroment) soon, maybe when switching to libxml3 if it
>> >ever get released :-)
>> > I will play with the tarball generation,
>>
>> I guess I am better with cvs than with tar, because I would find
>> much, much faster to reoroganize the repository than figure out
>> how to make tar so this!
>
> I don't ask you to do it, I will ... Next revision of libxml tar will
>have an include/libxml/ subtree containing the .h files.
Yay!
---- Message from the list xml@rpmfind.net Archived at : http://xmlsoft.org/messages/ to unsubscribe: echo "unsubscribe xml" | mail majordomo@rpmfind.net
This archive was generated by hypermail 2b29 : Tue Oct 03 2000 - 10:43:42 EDT