[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Repository organization for complex project

From: David Weintraub <qazwart_at_gmail.com>
Date: Wed, 13 Oct 2010 14:19:31 -0400

On Wed, Oct 13, 2010 at 1:42 PM, Les Mikesell <lesmikesell_at_gmail.com> wrote:
> How would you access them if you don't have java/maven/ivy when you want to
> retrieve a certain version?

Before we adopted our Ant projects to use Maven, we simply used the
<get> task. You can always download from a Maven repository using the
"get" and "wget" commands. Maven repositories, after all, are HTTP
accessible. There's no real reason why you can't user wget and curl to
do the fetching if you aren't a Java shop.

Uploading is trickier though. We simply used a shell script that
generated the correct "mvn install-file" command and didn't have to
generate a POM. Maven and Java are fairly easy to install and use open
source licenses, so there isn't really a big deal to install them.
With the "mvn install-file", we didnt' even have to create a pom.xml
file. We could build the command on the fly with just a shell script.

But, there's really no reason that you HAVE to use a Maven repository.
All you need is a remote storage directory and the concept of version
numbers. I'd setup the repository to use Mavenish concept of object
with sub-directories for each release and embedd the release into the
object between the object's name and suffix. For example, if Project B
produced a library libprojb.so, I'd call the thing libprojb-3.2.so,
and store it in my projectb/3.2 directory.

Imagine if you take the approach of checking into your repository the
libprojb.so library for Project A to use. What usually happens is that
you have a lib directory under your project with a libprojb.so
directory in it. You have no idea what files went into this directory
or what version it was from. Two years from now, that libprojb.so
directory will still be there and no one will know anything about it.

However, imagine if in Project A's make file is a macro
PROJB-LIB=projb/3.2, and later on, it uses this information to do a
scp from the release repository. You can look at that particular
version of Project A and say "Ah! It uses version 3.2 of Project B.
Since we tagged the source code used for that version of Project B as
3.2, we can still trace down the correct version. And, we can see that
the next release of Project A uses version 3.3 of Project B.

-- 
David Weintraub
qazwart_at_gmail.com
Received on 2010-10-13 20:20:08 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.