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

Re: Applications and Projects

From: Ben Collins-Sussman <sussman_at_collab.net>
Date: 2004-09-14 17:18:33 CEST

On Tue, 2004-09-14 at 08:08, Brooke Smith wrote:
> Thanks Ben, but no, the repository, working copy and export all need to
> be 'flat' with only one App1, App2 (... and AppN).
>
> Given that, what do you think about the (non-svn) 'depends' property I
> introduced in my first mail in this thread (from last mail I sent):
>
> "What do you think of the 'depends' property I suggested as a solution,
> where a modified "svn export" would use the values to handle exporting
> the dependencies also. The depends property would be set on each
> project and list the Apps that it depends on. Then when the export is
> done, the Apps are exported also. I may be able to use this for
> checkouts, though I'll have to do some experimentation to find out what
> problems this may raise."
>
> To confirm what I mean, when a Project is exported, the exporting
> script would check if a 'depends' property is set on the project and if
> so it would issue separate "svn export" commands for each one listed.
> This should be able to deliver the export:
>
> App1
> App2
> Proj1
> Proj2
>
> Anyone any thoughts about this?

I still don't understand what you want. The repository is all 'flat',
fine. Working copies are 'flat'. So you want a behavior whereby you run

   $ svn export URL-to-Proj1

... and you end up with a whole bunch of exported directories, side by
side?

   $ ls
   Proj1/ Proj2/ App1/ App2/
     
If this is what you want, then heck, you don't need to change svn's
source code. Just write your own 'export' script which looks for a
custom 'depends' property which you invent and attach to directories.
It parses the property value, and issues a bunch of 'svn export'
commands. Extremely simple.

This is exactly why properties are open-ended things. I can't see any
reason to put this functionality into the core svn code; at least, I've
never heard of anyone ever wanting to do something like this.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Sep 14 17:20:59 2004

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