I need help with project concept

Sorry to post across the userlists.

I'm using Subversion, Ant, and Anthill OS to automate my projects.  We 
release many products in different projects.

Currently I have set up a property sheet in Anthill for each project's 
build.xml and everything works fine.  However, many of the projects create a 
.jar file which is used or needed by other projects.  I tell my build.xml 
file in each project where to get the compiled jar files.

With so many jar files being copied all over and our projects growing larger 
and larger daily, I was asked to create my own top parallel project and call 
all the build files from my master proj and make this project the exchange 
folder for all the jar files or any other artifact.  It's a cleaner way, of 
course and more contained but it entails more work on my part.

I've got my master build file to work, running at the cmnd prompt, however, 
Anthill does not like it when you tell a build file to check out other top 
level project files from the repo.  Should I create dummy project files in 
Anthill just to check out the other projects and then let my build file take 
control?

Somebody please give me guidance on the big picture.  Is this a good idea to 
have a master and separate build project aware of all the other projects and 
but the other projects not being aware of it? How do I bypass the Anthill's 
shortcoming? By switching to CruiseControl?  Are there or do you have any 
examples I could see please?

_________________________________________________________________
Express yourself instantly with MSN Messenger! Download today - it's FREE! 

I need help with project concept

Sorry to post across the userlists.

I'm using Subversion, Ant, and Anthill OS to automate my projects.  We 
release many products in different projects.

Currently I have set up a property sheet in Anthill for each project's 
build.xml and everything works fine.  However, many of the projects create a 
.jar file which is used or needed by other projects.  I tell my build.xml 
file in each project where to get the compiled jar files.

With so many jar files being copied all over and our projects growing larger 
and larger daily, I was asked to create my own top parallel project and call 
all the build files from my master proj and make this project the exchange 
folder for all the jar files or any other artifact.  It's a cleaner way, of 
course and more contained but it entails more work on my part.

I've got my master build file to work, running at the cmnd prompt, however, 
Anthill does not like it when you tell a build file to check out other top 
level project files from the repo.  Should I create dummy project files in 
Anthill just to check out the other projects and then let my build file take 
control?

Somebody please give me guidance on the big picture.  Is this a good idea to 
have a master and separate build project aware of all the other projects and 
but the other projects not being aware of it? How do I bypass the Anthill's 
shortcoming? By switching to CruiseControl?  Are there or do you have any 
examples I could see please?

_________________________________________________________________
FREE pop-up blocking with the new MSN Toolbar – get it now! 

Re: I need help with project concept

Res,

I believe this is a fairly classic dependency management question with 
several decent answers. The 'master build script' approach you have 
taken is somewhat similar to the approach some Maven projects take. 
Personally, I'm not a big fan of the approach, but it certainly works 
for a number of organizations.

Anthill does have a dependency support mechanism of its own. At a high 
level what it does is allow you to specify groups of projects that have 
dependency relationships. You would then build these groups of projects 
together and Anthill would tell your build scripts where to find the 
shared jars - and likewise where to deliver the jars. You would need to 
tweak your build scripts, but probably wouldn't need to overhaul them. 
If this sounds like a viable approach, let us know and we can talk about 
that in more depth. As a side note, Anthill Pro does something similar 
but uses a different model to manage the dependencies. If the Anthill OS 
model doesn't work for you, it might be worth a look.

If you are really serious about dependencies and don't really want your 
build system managing them, I would use Ivy. The tool has been out for 
about a year and while young is really nice. Instead of copying jar 
files around, you use ivy to 'publish' them to a repository. Each 
project will also have a file where you list out the jars (and versions 
of jars) it is dependent on. When you start a build, you run an Ant task 
to retrieve the dependencies first thing. The repository is usually just 
files copied to the file system, but I believe there are extensions 
available to back it to Subversion.

The nice thing about Ivy is that dependencies are handled the same way 

SWIG bindings not makeing on Subversion 1.3.0, SWIG 1.3.28 or 1.3.24 and Python 2.4

Hi,

make swip-py, make swig-pl, make swig-rb don't work on my installation.
I'm using the .tar.gz form the 1.3.0 version off of subversion.tigris.org.
The compiler complains about a syntaxe error on a incorrectly defined
Macro SWIGRUNTIME on svn_clint.c in subversion/bindings/swig/python/.
I'm using SWIG 1.3.28 or 1.3.24 and Python 2.4 on a Debian Sarge.
Automake 1.9.

Here is the message (much too long to show in its entirety) :

/bin/sh /home/chris/loginst/subversion-1.3.0/libtool --tag=CC --silent
--mode=compile gcc -pthread -fno-strict-aliasing -DNDEBUG -g -O3 -Wall
-Wstrict-prototypes -fPIC -DLINUX=2 -D_REENTRANT -D_XOPEN_SOURCE=500
-D_BSD_SOURCE -D_SVID_SOURCE -D_GNU_SOURCE
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/include
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/proxy
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/proxy
-I/home/chris/loginst/subversion-1.3.0/subversion/include
-I/home/chris/loginst/subversion-1.3.0/apr/include
-I/home/chris/loginst/subversion-1.3.0/apr-util/include
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/include
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/proxy
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/proxy
-I/home/chris/loginst/subversion-1.3.0/subversion/include
-I/home/chris/loginst/subversion-1.3.0/apr/include
-I/home/chris/loginst/subversion-1.3.0/apr-util/include
-I/usr/include/python2.4

Re: SWIG bindings not makeing on Subversion 1.3.0, SWIG 1.3.28 or 1.3.24 and Python 2.4

[Christopher Mann]
> make swip-py, make swig-pl, make swig-rb don't work on my
> installation.  I'm using the .tar.gz form the 1.3.0 version off of
> subversion.tigris.org.  The compiler complains about a syntaxe error
> on a incorrectly defined Macro SWIGRUNTIME on svn_clint.c in
> subversion/bindings/swig/python/.  I'm using SWIG 1.3.28 or 1.3.24
> and Python 2.4 on a Debian Sarge.  Automake 1.9.

swig 1.3.28 is not shipped with sarge, and python2.4 isn't the default.
It's pretty easy to throw the world into confusion by using both
/usr/bin/python2.4 and /usr/bin/python (or #!/usr/bin/env python, which
amounts to the same thing, python 2.3).

It is reported to me (though I haven't tried it) that our Debian
unstable package builds fine on sarge if you do the following:

  debian/rules:
    - comment out the ENABLE_JAVAHL := yes at the top
  debian/control:
    - remove the kaffe and junit stuff from the Build-Depends line
    - change two instances of "libneon25-dev" to "libneon24-dev"

Our current unstable package (1.3.0-2) isn't available on the mirrors
yet, due to factors beyond our control, but for now you can pull it
from http://p12n.org/tmp/svn/.

HTH,
Peter

Re: SWIG bindings not makeing on Subversion 1.3.0, SWIG 1.3.28 or 1.3.24 and Python 2.4

The Debian "unstable" subversion package is 1.2.3 [1]

[1] 
http://packages.debian.org/cgi-bin/search_packages.pl?keywords=subversion&searchon=names&subword=1&version=unstable&release=all

I was able to compile the swig bindings (albiet with some warnings) when 
using the 1.2.3 source.

The problem is that the 1.2.3 source compiles the swig bindings just 
fine whereas the 1.3.0 does not.  Il also tried 1.3.0 with SWIG 1.3.24 
and Python 2.3, PERL, RUBY with the same results : works for 1.2.3 but 
not for 1.3.0.

Many thanks,

Chris

Should I enter this as a bug ?

Peter Samuelson a écrit :
> [Christopher Mann]
>   
>> make swip-py, make swig-pl, make swig-rb don't work on my
>> installation.  I'm using the .tar.gz form the 1.3.0 version off of
>> subversion.tigris.org.  The compiler complains about a syntaxe error
>> on a incorrectly defined Macro SWIGRUNTIME on svn_clint.c in
>> subversion/bindings/swig/python/.  I'm using SWIG 1.3.28 or 1.3.24
>> and Python 2.4 on a Debian Sarge.  Automake 1.9.
>>     
>

The Saga of My Disparate Build Process continues...

We have 3 or 4 projects under Subversion repository control.  Originally I 
had piggy backed along each project's build.xml file to package my Release 
Builds, increment build numbers, check in files, and tag the repository.  I 
even took advantage of Ant-Contrib's if/then/else statement to determine, 
whether a build was a branch or trunk build and package and number it 
accordingly.

I'm now working on organizing my own project at the top level alongside & 
parallel to the other projects where my build.xml will call each project's 
build.xml specific targets, or I may just run their build files target then 
have my build.xml to kick in to copy the artifacts to my project to be 
packaged or some of them to be checked in if necessary, number the build, 
check in the files in those projects and tag them.

My problem is the last part, tagging, due to being outside of each project 
and not being respository-aware.  If I were inside each project, this would 
not be an issue, however, being outside, how am I going to determine where 
I'm in relation to a project and whether that project is branch or trunk?

A question I have for the Subversion group specifically, could I use 
svn:externals to virtually link the build subfolder in my project into each 
project?  I probably should rename my build subfolder to a differ folder not 
to interfere with each proj's build subfolder?

Thanks.

_________________________________________________________________
Don’t just search. Find. Check out the new MSN Search! 
http://search.msn.click-url.com/go/onm00200636ave/direct/01/

svn add and commit problem ?

Hi,

I have a svn server via http on a apache2 web server. The commit, update 
works fine. The only problem is when I add a file on my working directory.
The commit return the following error :

svn: Commit failed (details follow):
svn: PROPFIND request failed on '/svn/EmploiNet/trunk/Script/toto'
svn: PROPFIND of '/svn/EmploiNet/trunk/Script/toto': 302 Found 
(http://xxxxx)

I think the problem is in my virtual host ?

An idea ? I try to put

<Location /svn>
DAV svn
SVNParentPath /home/www-data/svn/
</Location>
in apache2.conf or in mods-enabled/dav_svn.conf and in site-available 
but always the same result.
I work on the last Debian stable. My DocumentRoot is /home/www-data

Thanks for help. On a web server without virtual host, no problem. We 
svnserve, it's also work fine.

FSVS 1.0.5 released

Hello everybody,

FSVS 1.0.5 is released.

----- Excerpt from http://fsvs.tigris.org

FSVS stands for “Fast System VerSioning”, “File System VerSioning” or
“Full System VerSioning”. It aims to become a complete backup/restore tool
for all files in a directory tree or whole filesystems, with a subversion
repository as the backend.
You may think of it as some kind of tar or rsync with versioned storage.

----- Excerpt ends

The new release got some bugs fixed; it's notable points are
- testing framework extended with new tests.
  You'll need rsync 2.6.7 to complete the tests successfull, though.
- update and commit now write MD5 checksums for blocks of variable size,
  to accelerate checking for changed files (note: only applies if
  size equal to expected value, but timestamp changed).
  In the future I'd hope to send only changed data into the repository,
  using that mechanism.
- export command added for easier recovery of files/directories.
- can optionally checksum *all* files, not only changed (virus checking)
- a small compatibility fix (subversion uses "link " for symlinks, fsvs
  used "link:")
- a few small performance updates.

I know that I'm missing a 1.0.4 release, but that was already taken for
another snapshot (which wasn't released); it doesn't cause me headaches.

AW: FSVS 1.0.5 released