Subversion stewardship organization.

This is to announce a new mailing list, svn-org <at> subversion.tigris.org,
and with it an initiative that has been developing behind the scenes
for some time.

The Subversion full committers are forming a lightweight non-profit
organization ("The Subversion Corporation", and yes, we like the name
too  ), to be able to represent Subversion's interests when
necessary.  For example, sometimes donors want a place to make a
donation: this new organization will be 501(c)(6) tax-exempt to
receive them, and gives us a framework for deciding what to do with
such funds.  There are also (rare) instances where someone uses the
Subversion name in a way that might cause confusion.  Fortunately,
these have mostly been unintentional and resolvable amicably -- but as
Subversion becomes more popular, that will not always be the case, and
we'd like to be prepared so we can act quickly if/when the time comes.

PLEASE NOTE THAT SUBVERSION'S OPEN SOURCE LICENSE REMAINS THE SAME.
Subversion is and always will be open source; this new organization
does not affect that.

CollabNet has volunteered to act as a trustee (i.e., to provide legal
services, pay filing fees, etc) on the organization's behalf.  The
non-profit is wholly independent of CollabNet, however, and the
trusteeship agreement will be revocable by either party.  Also, we
expect an outside counsel, the Software Freedom Law Center, to be
reviewing all these arrangements pro bono, once the organization is
fully incorporated.

Status so far:

RE: svn.collab.net migration (basically) complete.

On Wednesday, March 15, 2006 2:20 AM, C. Michael Pilato wrote:

> in a closet of the CollabNet Chicago office which is
> now inhabited by exactly one person.

I hate to think of the working conditions when there were more than one!
Based on the successful migration, will they let you inhabit the rest of
the office? 

> I'm very happy.

I guess so!

Sorry for the waste of bandwidth, couldn't resist.

ThreadFind: get mailing list archive URLs faster

These two lists (dev <at>  and users <at> subversion.tigris.org) are now being
monitored by a ThreadFind instance:

   http://www.red-bean.com/threadfind/

Visit that page to see what it's all about, but the short story is:

If you have a mailing list post locally (in your mailreader or
whatever), just grab the Message-ID header from that message, give it
to the ThreadFind server above, and in return get the message's
archive URL and other useful data.  For example, if you enter:

   1142296987.12402.2.camel <at> egyptian-gods.mit.edu

you'll get this back:

   http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=113710
   (Thread URL: http://[...]/BrowseList?list=dev&by=thread&from=443479)
   Message-ID: 1142296987.12402.2.camel <at> egyptian-gods.mit.edu
   From: Greg Hudson <ghudson <at> MIT.EDU>
   References: <1142217211.20401.5.camel <at> linux.site>
   	 <85bqwb3ryd.fsf <at> newton.ch.collab.net>
   	 <1142258302.20401.39.camel <at> linux.site>
   To: Daniel Berlin <dberlin <at> dberlin.org>
   Cc: Svn Dev <dev <at> subversion.tigris.org>
   Subject: Re: [PATCH]: Let users cancel out of command line client
            immediately if they signal 3 times
   Date: Mon, 13 Mar 2006 19:43:06 -0500

Much thanks to Madan U S <madan <at> collab.net> for his work on this.

svn.collab.net migration (basically) complete.

The new svn.collab.net server is up-and-running, and as far as I can tell,
the migration went successfully.  Note that for some folks, it will take a
while for the DNS changes to propogate fully, so you'll need to force your
computer to believe that svn.collab.net can be found at 204.16.104.102.

Why the migration?  Put simply, the old box was a 700MHz desktop machine,
with 256 megs of RAM, running RedHat 7.1, and sitting in a closet of the
CollabNet Chicago office which is now inhabited by exactly one person.
Upgrading any package on the system was a major ordeal, almost always
leading to a source build.  And with only one person in physical contact
with the box (and him only working four days a week), emergency in-person
attention was becoming a difficult proposition.

So I (with Karl Fogel, that lone Chicago CollabNetter) petitioned CollabNet
for a newer desktop machine, to be housed in the fully staffed CollabNet
Brisbane office.  They one-upped us, offering a server-class machine in
their colo facility.  We graciously accepted.  The new box is a dual 3+GHz
machine with a gig of memory, double the disk space and a nice RHEL3 install.

I'm very happy.  I hope you are, too.

Note that there are still some cosmetic changes which might appear (ViewVC
stylesheet tweaks and such), but I don't know of anything which would
necessitate an interruption of service in the near future.

Among other things, this upgrade made possible the enabling of the ViewVC
commit database integration.  Check it out here:

   http://svn.collab.net/viewvc/svn/?view=queryform

AW: FSVS 1.0.5 released

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.

Do not hesitate to contact me for questions and problems.

Regards,

Phil

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/

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
-I/home/chris/loginst/subversion-1.3.0/subversion/bindings/swig/python/libsvn_swig_py 

-prefer-pic -c -o subversion/bindings/swig/python/svn_client.lo
subversion/bindings/swig/python/svn_client.c
In file included from /usr/include/python2.4/Python.h:8,
                 from subversion/bindings/swig/python/svn_client.c:22:
/usr/include/python2.4/pyconfig.h:841:1: warning: "_XOPEN_SOURCE" redefined
<command line>:8:1: warning: this is the location of the previous definition
subversion/bindings/swig/python/svn_client.c:111: error: syntax error
before "int"
subversion/bindings/swig/python/svn_client.c:126: error: syntax error
before "int"
subversion/bindings/swig/python/svn_client.c:145: error: syntax error
before "int"
subversion/bindings/swig/python/svn_client.c:186: error: syntax error
before "swig_cast_info"
subversion/bindings/swig/python/svn_client.c:192: error: syntax error
before "swig_cast_info"
subversion/bindings/swig/python/svn_client.c:200: error: syntax error
before "SWIGINLINE"
subversion/bindings/swig/python/svn_client.c:200: error: syntax error
before "void"
subversion/bindings/swig/python/svn_client.c:208: error: syntax error
before "swig_type_info"
subversion/bindings/swig/python/svn_client.c:222: error: syntax error
before "SWIGINLINE"
subversion/bindings/swig/python/svn_client.c:222: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:231: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:251: error: syntax error
before "void"
subversion/bindings/swig/python/svn_client.c:274: error: syntax error
before "swig_type_info"
subversion/bindings/swig/python/svn_client.c:319: error: syntax error
before "swig_type_info"
subversion/bindings/swig/python/svn_client.c:349: error: syntax error
before "char"
subversion/bindings/swig/python/svn_client.c:365: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:393: error: syntax error
before "char"
subversion/bindings/swig/python/svn_client.c:404: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:417: error: syntax error
before "char"
subversion/bindings/swig/python/svn_client.c:432: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c: In function
`SWIG_TypeRegister':
subversion/bindings/swig/python/svn_client.c:493: warning: implicit
declaration of function `SWIG_TypeRegisterTL'
subversion/bindings/swig/python/svn_client.c:493: warning: return makes
pointer from integer without a cast
subversion/bindings/swig/python/svn_client.c: In function `SWIG_TypeQuery':
subversion/bindings/swig/python/svn_client.c:499: warning: implicit
declaration of function `SWIG_TypeQueryTL'
subversion/bindings/swig/python/svn_client.c:499: warning: return makes
pointer from integer without a cast
subversion/bindings/swig/python/svn_client.c: At top level:
subversion/bindings/swig/python/svn_client.c:504: error: redefinition of
`SWIG_TypeClientData'
subversion/bindings/swig/python/svn_client.c:252: error:
`SWIG_TypeClientData' previously defined here
subversion/bindings/swig/python/svn_client.c:504: warning:
`SWIG_TypeClientData' was declared `extern' and later `static'
subversion/bindings/swig/python/svn_client.c: In function
`SWIG_TypeClientData':
subversion/bindings/swig/python/svn_client.c:505: warning: implicit
declaration of function `SWIG_TypeClientDataTL'
subversion/bindings/swig/python/svn_client.c: In function
`SWIG_PropagateClientData':
subversion/bindings/swig/python/svn_client.c:515: warning: implicit
declaration of function `SWIG_PropagateClientDataTL'
subversion/bindings/swig/python/svn_client.c: At top level:
subversion/bindings/swig/python/svn_client.c:850: error: syntax error
before "void"
subversion/bindings/swig/python/svn_client.c:856: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:862: error: syntax error
before "int"
subversion/bindings/swig/python/svn_client.c:1015: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:1024: error: syntax error
before "const"
subversion/bindings/swig/python/svn_client.c:1030: error: syntax error
before "int"
subversion/bindings/swig/python/svn_client.c:1090: error: syntax error
before "void"
subversion/bindings/swig/python/svn_client.c:19293: warning:
initialization from incompatible pointer type
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[0]')
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[0]')
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[1]')
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[1]')
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[2]')
subversion/bindings/swig/python/svn_client.c:19293: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19293: warning: (near
initialization for `_swigt__p_svn_io_dirent_t[2]')
...
subversion/bindings/swig/python/svn_client.c:19299: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19299: warning: (near
initialization for
`_swigt__p_f_p_void_p_q_const__char_p_struct_svn_wc_status_t__void[2]')
subversion/bindings/swig/python/svn_client.c:19300: warning:
initialization from incompatible pointer type
subversion/bindings/swig/python/svn_client.c:19300: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19300: warning: (near
initialization for
`_swigt__p_f_p_apr_getopt_t_p_void_p_apr_pool_t__p_svn_error_t[0]')
subversion/bindings/swig/python/svn_client.c:19300: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19300: warning: (near
initialization for
`_swigt__p_f_p_apr_getopt_t_p_void_p_apr_pool_t__p_svn_error_t[0]')
...
subversion/bindings/swig/python/svn_client.c:19302: warning: (near
initialization for `_swigt__size_t[1]')
subversion/bindings/swig/python/svn_client.c:19302: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19302: warning: (near
initialization for `_swigt__size_t[2]')
subversion/bindings/swig/python/svn_client.c:19302: warning: excess
elements in struct initializer
subversion/bindings/swig/python/svn_client.c:19302: warning: (near
initialization for `_swigt__size_t[2]')
subversion/bindings/swig/python/svn_client.c:19303: warning:
initialization from incompatible pointer type

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! 
http://toolbar.msn.click-url.com/go/onm00200415ave/direct/01/

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! 
http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/

RE: RE: [DESIGN] Aliases?

> -----Original Message-----
> From: Gale, David [mailto:David.Gale <at> Hypertherm.com]
> Sent: Monday, February 27, 2006 4:12 PM
> To: Frank Gruman
> Cc: Greg Hudson; users <at> subversion.tigris.org;
dev <at> subversion.tigris.org
> Subject: RE: [DESIGN] Aliases?

[snip]

> Ok, so, under my system, you hit release 1 and tag it; you find a bug,
> and issue a "svn copy -r REL_1 <repos>/trunk <repos>/branches/1.1-fix"
> command.  Amazingly enough, SVN's branching functionality supports
this.

I need to know what trunk/branch the tag ACTUALLY refers to for this to
work. What if REL_1 of the application was actually released off a
(different) branch? This scheme is only meaningful in the context of a
convention of how you layout your repository and when/where you release
versions of your code from. A user could just as easily do:

'svn copy -r REL_1 <repos>/branches/rel_2_dev <repos>/branches/1.1-fix'

From the context of the command this is correct and would return you a
copy of the code that - because you passed the REL_1 tag - you assume to
be REL_1 of the code, yet it isn't. The REL_1 tag in your example is
only meaningful when knowing what subsection of the repository it
actually relates to.