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

Re: [PATCH] new property 'svn:tarballs'

From: Christian Daudt <csd_ob_at_daudt.org>
Date: 2003-07-14 20:18:29 CEST

On Sunday 13 July 2003 03:23, Philip Martin wrote:
> "SteveKing" <steveking@gmx.ch> writes:
> > From: "Ben Collins-Sussman" <sussman@collab.net>
> >
> >> Many tools have crossed this line already: for example, clearcase has
> >> its own 'make' program. It scares me.
> >
> > Why does this scare you? I don't know clearcase at all, but
> > I guess that you're not forced to use the build tool but it's
> > optional?
>
> It's optional. One of the reasons for ClearMake is that it handles the
> problems conventional make has when versioned timestamps move
> backwards in time.
>
> I'm not all that keen on svn:tarballs, but I'm not all that keen on
> svn:externals either. Is anyone using svn:externals? Is it much
> better than doing the same thing outside the client (manually or via a
> script)?

Actually I recently started using it but I'm not too happy with the results. I
used it to solve the following situation: I have about 4 programs which have
their own svn trees (and 3 of which have to have a distinct tree because they
are a mix of in-house code + imported code). I then need a project which
grabs these 4 programs, builds them, and packs them together along with
configuration files and documentation (in my case it is a ISO image but it
could be a tarball, makes no difference).
 It seemed that svn:externals would solve my problem, but not really. The
problem persists in that there is no way for my to tag (svn cp) my iso
project and have that tag apply to the component programs also (the
svn:externals still points to wherever in the component trees I originally
set them to).
 I guess I'd need a meta-project project with capability to track/tag the
subprojects (btw: cvs modules does allow you to do that).

 csd

PS: The short answer to your question is: "svn:externals" isn't terribly
useful in its current incarnation IMHO.

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Jul 14 20:20:22 2003

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

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