[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: Bill Comisky <bcomisky_at_pobox.com>
Date: 2003-07-14 20:50:53 CEST

On Mon, 14 Jul 2003, Christian Daudt wrote:

> 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.

I use svn:externals within a repository to provide the equivalent of a
symbolic link between versioned directories. In my case I have multiple
customers that use all or a subset of version controlled directories
containing scripts. For example:

repo/cust1/dirA
          /dirB
          /dirC
          /dirD

repo/cust2/dirA
          /dirD

repo/cust3/dirA
          /dirB
          /dirC

In addition there are a few custom files for each customer. I don't want
to use 'svn copy' since I want changes in common code to propagate to each
customer's tree without having to 'svn merge' constantly.

There is still the problem with tagging (issue 1258). But since I am
working in the same repository, I know the revision number I want (since
they are all the same), and I just wrote a script to tag and then update
svn:externals of the tag to thumbtack the revision numbers manually. So
svn:externals isnt't perfect, but I do get to put the custom files and the
directory structure I need under version control.

If there's a simpler or more elegant solution to do what I want without
using svn:externals (using an svn feature or a script) I'm all ears. I
guess ideally what I would want is an 'svn ln' command that would work on
the repository similarly to 'svn cp'. In such a way of course that the
problems with using svn:externals for my intra-repository linking
(tagging, recursive commits/status) would go away.

bill

-- 
Bill Comisky
bcomisky@pobox.com
---------------------------------------------------------------------
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:51:46 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.