Trial migration of wiki and svn
Robert Osfield
Through last week Jose Luis Hidalgo has been working on doing a trial
migration to DreamHost by setting up access to his own DH account.
The wiki can be found at:
With the subversion repository sitting below this in the osg/ directory:
http://osg.codemaniacs.com/osg
You'll need to use the user name "guest" and password "guest" to
browse/checout the directories with read access.
I have been learning a bit about svn, but still am very much a novice.
So far everything I've wanted to do I've been able to track down how
to do it. The OpenSceneGraph project trunk checked in with the
deprecated directories still in place, so I've pruned these, and yes
svn makes this more straightforward than cvs :-)
To checkout the triple set you'd use something like:
svn checkout http://osg.codemaniacs.com/osg/OpenThreads/trunk OpenThreads
svn checkout http://osg.codemaniacs.com/osg/Producer/trunk Producer
svn checkout http://osg.codemaniacs.com/osg/OpenSceneGraph/trunk
OpenSceneGraph
Now one little caveat is that the Producer cvs snapshot I gave Jose to
import was one that had compile problems in it, but since the import
included all the tags we can just check that out instead of the
Producer trunk:
svn checkout http://osg.codemaniacs.com/osg/Producer/tags/Producer_OpenSceneGraph_BranchPoint/
Producer
Feel free to experiment, provide feedback.
Many thanks to Jose for setting this up,
Robert.
Jose Luis Hidalgo
Wiki seems to work, but there are some functions that are not working :
- change a wiki page
- delete content
- search content using wiki engine
- maybe sessions (but if you are not changing anything or
deleting, they don't apply)
I suspect that is a problem with php version ( the servers works with
php 5 and maybe the addons to pmwiki were done in php 4) I will try to
look at it and see what can be done.
Other problem with the current pmwiki is it can not be directly
updated to the last pmpwiki because the syntax of the wiki pages have
changed between versions. So, If we feel like we need to upgrade the
wiki, the effort of migrate content from the old wiki to the new one
will be the same, no matter if is an upgrade of pmwiki or a completely
different wiki.
IMHO we need to change the wiki... keep the "old" running for
historical reasons until everything is checked into the new wiki. That
is something to discuss here because is the community who has to do
the effort of migrate contents.
My very reasons to change:
- osg needs a new wiki (*avoid html-frames*, give a new and
polished look, ...)
- we can let the other wiki be read-only --> that means I don't
need change wiki code
- if we setup Trac, good integration with subversion
- less changes to the current wiki code ( I repeat this because it
causes me headache XDDD)
- make the current wiki work costs as much (in fact, much more)
as setup a new wiki.
Cons:
- we need to make the effort of migrate contents...
- one more thing to worry about... but I think community can handle this.
Cheers,
Jose L.
--
Jose L. Hidalgo Valiño (PpluX)
---- http://www.pplux.com ----
Shue, John
I get the following error:
Error: Failed to add directory
'C:\working\svn-OSG\Producer\VC++6.0\producer': object of the same name
already exists
Looking at the repository, I see that there are 2 directories that are
different only by the capitalization of the first letter. Also the
problem "producer" directory is empty. Is this an old directory that
needs to be pruned?
If I check out the Producer_OpenSceneGraph_BranchPoint tag, everything
works great.
OpenThreads and OpenSceneGraph trunks checkout without problem on
Windows.
I'll continue to play around with the Subversion.
-john
Hi All,
http://osg.codemaniacs.com/osg
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you.
Shue, John
but I'm not sure if it is something bad that happened locally:
Error: In directory
'C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph'
Error: Can't move source to dest
Error: Can't move
'C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\.svn\tmp\prop-ba
se\osgviewer-Info.plist.svn-base' to
'C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\.svn\prop-base\o
sgviewer-Info.plist.svn-base': The system cannot find the file
Error: specified.
I'll look into it more and report back.
Robert Osfield
On 11/20/06, Shue, John <John...@mantech-ist.com> wrote:
> While performing a svn checkout of the Producer trunk on my Windows box,
> I get the following error:
>
> Error: Failed to add directory
> 'C:\working\svn-OSG\Producer\VC++6.0\producer': object of the same name
> already exists
>
> Looking at the repository, I see that there are 2 directories that are
> different only by the capitalization of the first letter. Also the
> problem "producer" directory is empty. Is this an old directory that
> needs to be pruned?
It looks to be the same problem as came across with OpenSceneGraph,
with the old directories that a pruned with -Pd under cvs need
manually pruning from svn. This is an import issue rather than an svn
issue.
Robert.
Robert Osfield
What is the source of this errors? The Xcode files themselves are not
relevant for windows.
Robert.
On 11/20/06, Shue, John <John...@mantech-ist.com> wrote:
>
Shue, John
windows where when checking out, the software uses a temporary file
until the entire file is received, and then moves/copies the file into
its proper place. This last step sometimes causes problems when the
Windows box is under heavy load.
I'll retry the checkout when I have a spare moment.
-john
> -----Original Message-----
> From: osg-...@googlegroups.com
> [mailto:osg-...@googlegroups.com] On Behalf Of Robert Osfield
> Sent: Monday, November 20, 2006 8:31 AM
> To: osg-...@googlegroups.com
> Subject: [osg-crew] Re: Trial migration of wiki and svn
>
>
Robert Osfield
On 11/20/06, Jose Luis Hidalgo <joseluis...@gmail.com> wrote:
> Wiki seems to work, but there are some functions that are not working :
> - change a wiki page
> - delete content
> - search content using wiki engine
> - maybe sessions (but if you are not changing anything or
> deleting, they don't apply)
>
> I suspect that is a problem with php version ( the servers works with
> php 5 and maybe the addons to pmwiki were done in php 4) I will try to
> look at it and see what can be done.
>
> Other problem with the current pmwiki is it can not be directly
> updated to the last pmpwiki because the syntax of the wiki pages have
> changed between versions.
Rainer Oder is the author of the curent PmWiki setup so hopefully
he'll be able help out smooth over such issues.
> So, If we feel like we need to upgrade the
> wiki, the effort of migrate content from the old wiki to the new one
> will be the same, no matter if is an upgrade of pmwiki or a completely
> different wiki.
Migration between PmWiki versions is less likely to hit syntax issues
than moving to a completely new wiki. I would hope that the PmWiki
authors have thought about this, and if there are differences will be
minor or to provide migration paths.
> IMHO we need to change the wiki... keep the "old" running for
> historical reasons until everything is checked into the new wiki. That
> is something to discuss here because is the community who has to do
> the effort of migrate contents.
>
> My very reasons to change:
> - osg needs a new wiki (*avoid html-frames*, give a new and
> polished look, ...)
> - we can let the other wiki be read-only --> that means I don't
> need change wiki code
> - if we setup Trac, good integration with subversion
> - less changes to the current wiki code ( I repeat this because it
> causes me headache XDDD)
> - make the current wiki work costs as much (in fact, much more)
> as setup a new wiki.
>
> Cons:
> - we need to make the effort of migrate contents...
> - one more thing to worry about... but I think community can handle this.
While I'm open to have a new wiki and new look for the website. In
fact I believe we do need a new look and layout of the website.
While some of the community might be ready, willing and able to help
with migration to a new wiki right now then great, but its better to
be patient for a time when the core developers themselves are fully
bought on board and ready.
I for one am totally overloaded by my current set of tasks in front of
me, I absolutely can't take on any more new stuff. Migrating to a new
wiki would way too much too quickly, and would put me into very
serious danger of burnout and for many tasks to start suffering.
Right now I need less to worry about not more.
Give things a couple of months to start getting back on an even keel,
then we start getting more ambitious.
Robert.
Shue, John
same error. After looking into it further, it is another problem
related to Windows' lack of support for case-sensitive filenames. There
are 2 files in the Xcode directories with the same spelling and
different capitalization:
Added:
C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\osgViewer-Info.pl
ist
Added:
C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\osgviewer-Info.pl
ist
Anyone know if there is an easy way to go through a SVN repository
looking for filenames that only differ by case?
Robert Osfield
On 11/20/06, Shue, John <John...@mantech-ist.com> wrote:
>
> Tried the checkout of OpenSceneGraph trunk on another box and got the
> same error. After looking into it further, it is another problem
> related to Windows' lack of support for case-sensitive filenames. There
> are 2 files in the Xcode directories with the same spelling and
> different capitalization:
>
> Added:
> C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\osgViewer-Info.pl
> ist
> Added:
> C:\working\svn-OSG\OpenSceneGraph\Xcode\OpenSceneGraph\osgviewer-Info.pl
> ist
>
> Anyone know if there is an easy way to go through a SVN repository
> looking for filenames that only differ by case?
Curious, the files both exist in the CVS version of the OSG, one if
for the osgViewer library and the other for the osgviewer application,
so they are both valid.
This makes me wonder if the CVS version of the OSG also has this
problem, or whether the CVS client is doing something to walk around
this conflict.
One way to solve this would be to rename osgviewer-Info.plist to
osgviewer-application-Info.plist. However, this will break the OSX
build without other amendments to the Xcode projects as they are real
tangled web of dependencies.
Robert.
Rainer Oder
> Wiki seems to work, but there are some functions that are not working :
> - change a wiki page
> - delete content
> - search content using wiki engine
> - maybe sessions (but if you are not changing anything or
> deleting, they don't apply)
>
> I suspect that is a problem with php version ( the servers works with
> php 5 and maybe the addons to pmwiki were done in php 4) I will try to
> look at it and see what can be done.
>
> Other problem with the current pmwiki is it can not be directly
> updated to the last pmpwiki because the syntax of the wiki pages have
> changed between versions.
Rainer Oder is the author of the curent PmWiki setup so hopefully
he'll be able help out smooth over such issues.
W.r.t. the php version, this can't be an issue. PHP pretty much works solid between 4 and 5, except the support for OO-code.
> So, If we feel like we need to upgrade the
> wiki, the effort of migrate content from the old wiki to the new one
> will be the same, no matter if is an upgrade of pmwiki or a completely
> different wiki.
Migration between PmWiki versions is less likely to hit syntax issues
than moving to a completely new wiki. I would hope that the PmWiki
authors have thought about this, and if there are differences will be
minor or to provide migration paths.
Actually, I don't see why one would update the wiki version. What was the idea behind that?
Porting the current wiki is a matter of configuration, while porting it to a later version is much more of a task.
I'm happy to support everybody who tries to port the wiki to another server. Maybe one could provide a temporary ssh login.
Cheers,
Rainer
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
>
> Curious, the files both exist in the CVS version of the OSG, one if
> for the osgViewer library and the other for the osgviewer application,
> so they are both valid.
>
> This makes me wonder if the CVS version of the OSG also has this
> problem, or whether the CVS client is doing something to walk around
> this conflict.
AFAIK, CVS will silently replace one file with the other on Windows. On
Unix (or other case sensitive system) you will get two files, on Windows
just the one checked out later. It is a big mess :(
Subversion will protest if there is an existing file with the same filename.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFYit3n11XseNj94gRArioAKC0IMMAo63Gybt1SumJf1/r6mjeegCeJ7zg
P3gzxEkoS61fLj/d7rDYb34=
=lL5b
-----END PGP SIGNATURE-----
Robert Osfield
On 11/20/06, Jan Ciger <jan....@gmail.com> wrote:
> AFAIK, CVS will silently replace one file with the other on Windows. On
> Unix (or other case sensitive system) you will get two files, on Windows
> just the one checked out later. It is a big mess :(
>
> Subversion will protest if there is an existing file with the same filename.
Thanks for the explanation. So we need to rename the Xcode project in
CVS. I'll ping Eric with this info.
Robert.
Shue, John
after the initial cvs2svn import? I am contemplating doing a CVS -> SVN
move here at work and I know in the past we had some issues with case
sensitive filenames.
-john
-----Original Message-----
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On
Behalf Of Robert Osfield
Sent: Monday, November 20, 2006 6:07 PM
To: osg-...@googlegroups.com
Subject: [osg-crew] Re: Trial migration of wiki and svn
Hi Jan,
Robert.
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you.
Robert Osfield
On 11/21/06, Shue, John <John...@mantech-ist.com> wrote:
>
> BTW, what is the procedure to manually prune the directories in SVN
> after the initial cvs2svn import? I am contemplating doing a CVS -> SVN
> move here at work and I know in the past we had some issues with case
> sensitive filenames.
svn delete/copy/move is probably what you are looking for.
Robert.
Jose L. Hidalgo
On Nov 21, 4:52 am, "Shue, John" <John.S...@mantech-ist.com> wrote:
> BTW, what is the procedure to manually prune the directories in SVN
> after the initial cvs2svn import? I am contemplating doing a CVS -> SVN
> move here at work and I know in the past we had some issues with case
> sensitive filenames.
>
> -john
There is an option of cvs2svn to prune empty directories, in fact it
should
prune them by default because the option is "--no-prune --> don't prune
empty directories".
With the CVS -> SVN migration we test the other day we use a config
file and I missed this
option:
ctx.prune = False
Sorry!!! For the final version I will try not forget to set it to True
to prune them.
(May I make another test? could I remove the current subversion and try
import the latests cvs
repository but pruning the empty dirs?)
Jose L.
Robert Osfield
On 11/21/06, Jose L. Hidalgo <joseLuis...@gmail.com> wrote:
> There is an option of cvs2svn to prune empty directories, in fact it
> should
> prune them by default because the option is "--no-prune --> don't prune
> empty directories".
>
> With the CVS -> SVN migration we test the other day we use a config
> file and I missed this
> option:
> ctx.prune = False
>
> Sorry!!! For the final version I will try not forget to set it to True
> to prune them.
This is a pretty minor little hiccup, I consider the current svn a
darn good first attempt :)
> (May I make another test? could I remove the current subversion and try
> import the latests cvs
> repository but pruning the empty dirs?)
It'd be worth doing another trial. I think it'd be worth renaming all
the colliding names in the CVS version and then doing the new import.
Is it just the Xcode osgviewer files that are the colliding? Given
that the Producer/produce one will be pruned out anyway?
Robert.
Jose L. Hidalgo
On Nov 21, 10:21 am, "Robert Osfield" <robert.osfi...@gmail.com> wrote:
>It'd be worth doing another trial. I think it'd be worth renaming all
> the colliding names in the CVS version and then doing the new import.
>
> Is it just the Xcode osgviewer files that are the colliding? Given
> that the Producer/produce one will be pruned out anyway?
>
I'm actually making another dump, here in the "new" server, it's almost
complete
in fact (in DH it took 45 min to complete the dump, here only takes 5)
I'm using the
same snapshots from
http://openscenegraph.org/downloads/Server-snapshots.
I suppose the effect of pruning in the dump will be the same as the -Pd
option
for CVS which is the desired effect.
The **NEW** subversion repository to test with is :
https://www.okode.com/osg/svn/
This new version has the prune directive set to "True"...
Cheers,
Jose L.
PD: This new subversion repository is in a server of my University. I
will try to set up the wiki too, That will be useful to test speed and
compare with DH.
Robert Osfield
On 11/21/06, Jose L. Hidalgo <joseLuis...@gmail.com> wrote:
> I'm actually making another dump, here in the "new" server, it's almost
> complete
> in fact (in DH it took 45 min to complete the dump, here only takes 5)
> I'm using the
> same snapshots from
> http://openscenegraph.org/downloads/Server-snapshots.
>
> I suppose the effect of pruning in the dump will be the same as the -Pd
> option
> for CVS which is the desired effect.
>
> The **NEW** subversion repository to test with is :
> https://www.okode.com/osg/svn/
> This new version has the prune directive set to "True"...
Just had a look at the trunk doesn't seem to contain the pruned
directories so a thumbs up so far.
> PD: This new subversion repository is in a server of my University. I
> will try to set up the wiki too, That will be useful to test speed and
> compare with DH.
Is this server local your lab? Will it be the final candidate for a server?
Robert.
Jose L. Hidalgo
> Is this server local your lab? Will it be the final candidate for a server?
This will be the final candidate server (at first), it is in a special
room inside the institute with other servers. Currently we are trying
to move it to the university Data center or even buy a better one if
finally you decide to be hosted by UPV. The specifications of the
server are:
- Intel(R) Pentium(R) 4 CPU 3.40GHz HT and 2Gb of RAM
- RAID with 2 hard drives (200GB) in mirror, with SMART.
- 1 gigabit ethernet
- Ubuntu Dapper, Apache 2.0, PHP 5.0, Trac, Tracking Mantis, Tomcat
5.5 / J2EE 1.4, PostgreSQL 8 + MySQL 5, dotProject 2.0.2, Subversion
1.4, Samba, ProFTPD, Continuum, Gcc, java
I really feel they are enough, and no other big projects are hosted in
that server.
Jose L.
Shue, John
latest CVS code from OpenThreads, Producer, and OpenSceneGraph and only
found the Xcode osgViewer-Info.plist osgviewer-Info.plist match.
-john
-----Original Message-----
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On
Behalf Of Robert Osfield
Sent: Tuesday, November 21, 2006 4:21 AM
To: osg-...@googlegroups.com
Subject: [osg-crew] Re: Trial migration of wiki and svn
Hi Jose,
Robert.
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information. If the reader of this message is not the intended recipient, you are hereby notified that any dissemination, distribution, use or copying of this message is strictly prohibited. If you have received this in error, please reply immediately to the sender and delete this message. Thank you.
Robert Osfield
On 11/21/06, Shue, John <John...@mantech-ist.com> wrote:
> I wrote a simple python script to check for filename collisions on the
> latest CVS code from OpenThreads, Producer, and OpenSceneGraph and only
> found the Xcode osgViewer-Info.plist osgviewer-Info.plist match.
Thanks, I have just renamed osgviewer-Info.plist to
osgviewerApplication-Info.plist and changed the file external project
references to the file. This is now checked into OSG CVS.
Fingers crossed this won't break the OSX build...
Robert.
Shue, John
Is it possible to regenerate a new SVN repository with the recently
renamed Xcode filename that was interfering with the SVN checkout on
Windows?
In order to do that, I imagine Robert will have to create a new
snapshot...
-john
-----Original Message-----
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On
Behalf Of Jose L. Hidalgo
Sent: Tuesday, November 21, 2006 5:24 AM
To: osg-crew
Subject: [osg-crew] Re: Trial migration of wiki and svn
Hi Robert,
Cheers,
Jose L.
Jose Luis Hidalgo
Sure! only need Robert to create new (and updated) snapshots, and
2 very little scripts will do the rest.
Jose L.
On 11/22/06, Shue, John <John...@mantech-ist.com> wrote:
>
> Jose, Robert,
>
> Is it possible to regenerate a new SVN repository with the recently
> renamed Xcode filename that was interfering with the SVN checkout on
> Windows?
>
> In order to do that, I imagine Robert will have to create a new
> snapshot...
>
> -john
Robert Osfield
>
> Hi John,
> Sure! only need Robert to create new (and updated) snapshots, and
> 2 very little scripts will do the rest.
I'll make a snapshot this morning.
Robert.
Robert Osfield
OpenSceneGraph cvs repositories, you can can grab them from:
http://openscenegraph.org/downloads/Server-snapshots/
Note the wiki snapshot hasn't been updated.
Jose Luis Hidalgo
I've updated the svn with the latest cvs snapshots, you can find
the repository at https://pacman.ai2.upv.es/osg/svn/ (guest:guest)
Cheers,
Jose L.
On 11/22/06, Robert Osfield <robert....@gmail.com> wrote:
>
> I have just done the snapshot of OpenThreads, Producer and
> OpenSceneGraph cvs repositories, you can can grab them from:
>
> http://openscenegraph.org/downloads/Server-snapshots/
>
Robert Osfield
On 11/22/06, Jose Luis Hidalgo <joseluis...@gmail.com> wrote:
> I've updated the svn with the latest cvs snapshots, you can find
> the repository at https://pacman.ai2.upv.es/osg/svn/ (guest:guest)
I have run out of day and still haven't had an opportunity to test out
the new imports.
Tomorrow I'll check them out. If everything compiles file I guess
it'd be time to start telling osg-users about it to test it out fully.
Cheers,
Robert.
Jan Ciger
Hash: SHA1
Everything checked out and built OK, apart of the version of Producer in
the repo which barfed because I didn't have DWMake. Once I checked it
out using the instructions, it wasn't obvious how to build it with it,
so I have used my older copy instead.
Regards,
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFZNwgn11XseNj94gRAveDAJ9VP6D6avQkrDKEIgCa42W8eqWE1gCffuFf
sAkT0LmueIIrtoO1o3/Ny9Q=
=akAz
-----END PGP SIGNATURE-----
Shue, John
Producer, and OpenSceneGraph) on my Windows box from the SVN server.
Previous problems with case-sensitive filenames is gone.
I'm currently compiling on VS 2003. Looking good so far, OpenThreads and
Producer compiled successfully.
-john
-----Original Message-----
From: osg-...@googlegroups.com [mailto:osg-...@googlegroups.com] On
Behalf Of Robert Osfield
Sent: Wednesday, November 22, 2006 4:24 PM
To: osg-...@googlegroups.com
Subject: [osg-crew] Re: Trial migration of wiki and svn
HI Jose,
Cheers,
Robert.
This communication, along with any attachments, is covered by federal and state law governing electronic communications and may contain company proprietary and legally privileged information.
Robert Osfield
On 11/22/06, Jan Ciger <jan....@gmail.com> wrote:
> Everything checked out and built OK, apart of the version of Producer in
> the repo which barfed because I didn't have DWMake. Once I checked it
> out using the instructions, it wasn't obvious how to build it with it,
> so I have used my older copy instead.
I thought Don had decided to embed DWMake into Producer.
Robert.
Robert Osfield
On 11/23/06, Robert Osfield <robert....@gmail.com> wrote:
> I thought Don had decided to embed DWMake into Producer.
I have just checked out the svn Producer and found that DWMake does
look to be integrated into Producer, but it still requies the DWMAKE
env var to be set to locate the local Make directory.
export DWMAKE=/home/me/Test/Producer/Make
Should do the trick. I would have thought Don will be able to resolve
this glitch.
Robert.
Robert Osfield
> I have just checked out the svn Producer and found that DWMake does
> look to be integrated into Producer, but it still requies the DWMAKE
> env var to be set to locate the local Make directory.
>
> export DWMAKE=/home/me/Test/Producer/Make
>
I tried the above, but then couldn't get Producer to compile to
problems with linux 64 bit build, clearly the embedded DWMake isn't
quite a stable across platforms as the seperate distribution of DWMake
that I have installed so I've reverted to the later.
Moving on then I found that osgconv wouldn't compile due to
osgProducer not having a Xmu function, to fix this I had to add
${X_LIBS} to the GNUmakefile link line in osgProducer. I don't know
why this is suddenly needed, the core OSG hasn't changed, I can only
guess that Producer/DWMake build changes are having a knock on effect.
Robert.
Jan Ciger
Hash: SHA1
Ah, OK, didn't try that - I had checked it out extra but then didn't
really have time to investigate what was wrong with it.
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFZfBRn11XseNj94gRAoxFAJ99QOC7/ZTArNyOxrvxx58hwbenkwCgx2S3
/xMtRzQ+maUzs6tf+kdJLIo=
=s4Vo
-----END PGP SIGNATURE-----
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
> Moving on then I found that osgconv wouldn't compile due to
> osgProducer not having a Xmu function, to fix this I had to add
> ${X_LIBS} to the GNUmakefile link line in osgProducer. I don't know
> why this is suddenly needed, the core OSG hasn't changed, I can only
> guess that Producer/DWMake build changes are having a knock on effect.
>
> Robert.
Most likely the Xmu was removed from linking in Producer as unneeded and
now the linking fails in osgProducer.
Adding it there is better, IMHO - why pollute Producer with libraries it
doesn't need.
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFZfDVn11XseNj94gRAtM6AJ9HIeFtT1IyJ5EMex3uuPv9B7/45gCg8OWl
j+esNL3Xnpa/vA7SwNj5lWQ=
=ivH1
-----END PGP SIGNATURE-----
Robert Osfield
On 11/23/06, Jan Ciger <jan....@gmail.com> wrote:
> Most likely the Xmu was removed from linking in Producer as unneeded and
> now the linking fails in osgProducer.
>
> Adding it there is better, IMHO - why pollute Producer with libraries it
> doesn't need.
osgProducer doesn't use Xmu either. The only X in osgProducer comes
from Producer, and in theory Producer should be hiding this.
Producer is designed to hide the implementation details, so
osgProducer shouldn't need these to know how Producer wasn't
implemented nor what extra libs are required by it, but arn't linked
in directly.
Robert.
Jan Ciger
Hash: SHA1
Robert Osfield wrote:
> osgProducer doesn't use Xmu either. The only X in osgProducer comes
> from Producer, and in theory Producer should be hiding this.
>
> Producer is designed to hide the implementation details, so
> osgProducer shouldn't need these to know how Producer wasn't
> implemented nor what extra libs are required by it, but arn't linked
> in directly.
Hmm, then this should be reported to Don - I know that he was cleaning
up some of the linking recently and perhaps he removed what he shouldn't
and the problem was hidden for him since he linked it elsewhere. It
seems that the current state of the build of Producer is really a mess :(
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFZhXin11XseNj94gRAhGtAJ9LHuE0N/iWg8JcCvOGHaonc29ycQCeNfcQ
APo5mt9wLKGWIlRPlSnlwIg=
=DxzF
-----END PGP SIGNATURE-----
Robert Osfield
On 11/23/06, Jan Ciger <jan....@gmail.com> wrote:
> Hmm, then this should be reported to Don - I know that he was cleaning
> up some of the linking recently and perhaps he removed what he shouldn't
> and the problem was hidden for him since he linked it elsewhere. It
> seems that the current state of the build of Producer is really a mess :(
Personally I'm burnout from trying to engage with Don, others are
welcome to step in a help sort of the build issues.
I believe others are already testing and providing feedback to Don and
things are improved over the last week, but it clearly isn't yet on
par with how things were before going with DWMake so more work needs
to be done.
We always have the tag to fall back on in the meantime.
Robert.
mynam...@hotmail.com
syncing(checking out) files. Anybody else witness this?
Robert Osfield
On 11/28/06, z...@faac.com <mynam...@hotmail.com> wrote:
> I really like subversion. However, I found that it is a lot slower
> syncing(checking out) files. Anybody else witness this?
I haven't timed things yet, but a clean check out is a bit slow. cvs
has a compressed checkout option that certainly helps things along, I
haven't spotted anything similar with svn yet though, perhaps I've
just missed it.
Robert.
Jan Ciger
Hash: SHA1
You can always tunnel Subversion through SSH which has -C option to
compress traffic.
Jan
- --
Jan Ciger
GPG public key: http://www.keyserver.net/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)
Comment: Using GnuPG with Mandriva - http://enigmail.mozdev.org
iD8DBQFFbK3jn11XseNj94gRArrmAKDFm4V6TpKJYHWFuKo/LXsp7gkMkwCeI5XZ
XUyFDpHLwXI1Zi00lUpkSf8=
=62VS
-----END PGP SIGNATURE-----
Jose Luis Hidalgo
I haven't timed things yet, but a clean check out is a bit slow. cvs
has a compressed checkout option that certainly helps things along, I
haven't spotted anything similar with svn yet though, perhaps I've
just missed it.
I really still think subversion is much better than CVS, despite it isn't perfect.
Jose L.
Robert Osfield
On 11/29/06, Jose Luis Hidalgo <joseluis...@gmail.com> wrote:
> That's true, the initial check out is about twice slower than CVS... But I'm
> confident about the algorithm used for updating makes SVN faster than CVS
> in normal use. Anyway if we compare the time an user spends
> downloading/updating code with the time he/she spends compiling that code...
> this feels like a very minor problem. :)
From what I've gathered Subversion only sends changes to files rather
than whole files, so incremental updates will be faster.
> I really still think subversion is much better than CVS, despite it isn't
> perfect.
Well I'm not for turning back the clock, Subversion definitely has my
vote. Once we actually do a release then we'll find out just how good
it is, but so far its done just fine.
Robert.
Shue, John
server information posted to this list. I'm getting the following
error:
Error: PROPFIND request failed on '/osg/svn/OpenThreads/trunk'
Error: PROPFIND of '/osg/svn/OpenThreads/trunk': 405 Method Not Allowed
(https://pacman.ai2.upv.es)
Is pacman.ai2.upv.es still the latest SVN we're supposed to be testing
with?
-john
Paul Martz
Finally catching up.
Can someone fill me in on some background here? Why is there a copy of
Producer under SVN? Why wouldn't Producer users simply go to the normal
Producer home for this, like they do for libTIFF, gdal, etc?
Similarly, why is OpenThreads moving under SVN?
Confused,
-Paul
> -----Original Message-----
> From: osg-...@googlegroups.com
> [mailto:osg-...@googlegroups.com] On Behalf Of Jan Ciger
> Sent: Thursday, November 23, 2006 2:43 PM
> To: osg-...@googlegroups.com
> Subject: [osg-crew] Re: Trial migration of wiki and svn
>
>
Robert Osfield
On 12/1/06, Paul Martz <pma...@skew-matrix.com> wrote:
> Sorry I've not been active on this thread. I've been busy with other tasks.
> Finally catching up.
>
> Can someone fill me in on some background here? Why is there a copy of
> Producer under SVN? Why wouldn't Producer users simply go to the normal
> Producer home for this, like they do for libTIFF, gdal, etc?
>
> Similarly, why is OpenThreads moving under SVN?
Producer and OpenThreads have been imported to test the tripleset.
I have exchanged emails with Sean Spicer and he is keen to see us host
OpenThreads on the new server, and to do so under svn. I also raised
the question of project leadership as Sean has been way too busy to
engage much of last few years, and Sean is happy to see another
volunteer from the OpenThreads/OpenSceneGraph community step up and
take the reigns. This another topic that deserves discussing in a
separate thread, something for next week perhaps.
I don't know what Don would like to do with Producer, I presume he'll
want to host it himself, and whether he'll migrate to svn is down to
him. As far as I can tell these days its easy to set up and import.
From my own perspective I would like to see a family of OpenSceneGraph
related projects that all use the same version control, build systems
etc. User coming to the OSG then would at least get a feel for
coherency between them, and not have to go through learning different
version control systems, build systems etc.
I have the idea in my head to have an idea of the "Family and the
Forge" where a set of closely related projects make up a family of
OpenSceneGraph projects, while the Forge is where members of the
family are incubated, or slightly less core family members live (i..e
cousins etc). Members of the family would need to have stricter
adherence to a common template of how the project is put together, and
the central role it plays for OpenSceneGraph users.
Robert.