Sure, sounds like a good idea. Have you seen
http://subversion.tigris.org/issues/show_bug.cgi?id=3216
? :-)
-Karl
"G.Neiß" <g.neiss_at_plarad.de> writes:
>>I think the feature you're looking for is known as "client viewspecs",
> If I have understood everything all rigth inside the mentioned thread(s),
> the concept described there (client viewspecs) differes in one importend
> thing from what I proposed:
> 'client viewspecs' will introduce a 'special view' into the repository, that
> may or may not be enabled inside a checkout/working copy.
> That's something know from ClearCase, where You may specify a different view
> onto the same repository for every 'working copy' (which is called 'view' in
> ClearCase)....
>
> My poposal is more to extending the 'svn:external keyword' to handle sparse
> directories (more precise: sparse including of externals).
> This will:
> - NOT create/enable different views into a repository (all checkouts of this
> repository will be the same if no --depth is supplied when checking out)
> - but provide a way of 'linking in' (parts of) a repository path into
> another repository
> It's just like the existing 'svn:externals' works rigth now. You may
> add/include another repository (or only a subtree of it) into the working
> copy of a repository. At the time now using 'svn:externals' we are only able
> to include the complete (sub-)tree of the other repository into a working
> copy into a 'special' directory of that working copy.
> What I introduce was, that:
> - we expand 'svn:externals' to having an optional '--depth' parameter that
> works like this parameter for svn checkout, but only for this 'linked in'
> part.
> (That's the basic)
> Even it's not explicid stated, You may use the 'svn:externals' to 'include'
> a subtree of the same repository into a directory of Your working copy. This
> will produce a working copy where some files are checked out into two or
> more directories of Your working copy.
> OK under Linux I would not do it this way, I may use a 'directory link' to
> achive (almost) the same (doing it this way there are no real copies of the
> files, but all programms behave the same, because the links are followed
> naturaly by almost all programms).
> Under Windows this kind of 'linking in' isn't that common and a lot of tools
> will have problem to correctly following those links.
> So I (unfortunally) need to copy these files into different dirs.
> This is no real problem, because if You commit changes, then checkout again,
> changes done on one of this files are correctly handled (as long as You
> don't change both copies before trying to commit).
>
> Back to my example:
> I use a repository to hold a complete project.
> The 'developer' part is only for developers.
> When they release a new version, parts of this this must be 'transfered' to:
> - the customer CD (This CD hold the binaries & data files they shall use)
> - the maintenance people (they must get all files that the customers get,
> plus some extra binaries and some of their data files must be 'expanded')
>
> One Way of doing this is:
> Wenever a newer releas is made the files are copied into the designated
> folders.
> This is bad, because one file must be copied to mutiple folders and there is
> always a change that someone fogot one copy.
>
> Another way (Liniux style) would be:
> There is one tree for the (all) released files
> The other folders (CD,maintenance..) have only soft links to this files.
> When buring the CD You must enshure that the file the link refers to is
> placed onto the CD, not the link itsef.
> That's the part that doesn't work under Windows, because all CD buring prg's
> I know will simply place the link onto the CD :-((
>
> The way I try to use:
> Instead of using soft links, I use an svn:external that points to the
> corosponding subtree of the repository.
> So to burn a CD with the correct content, I use svn export into a temporary
> dir, then burn all files inside this dir onto the CD.
>
> I hope the difference is now clear.
>
> By simply adding the --depth parameter to svn:external we got this aditional
> feature.
>
> This is the current syntax for svn:externals (unfortunaly there is no EBNF
> definition in the book, I try to create it rigth here):
> <dir> [-r<revision>] <repository-path>
> Where
> dir: a subdir of the current dir of the WC where the external repository is
> checkout to (include into the WC)
> revision: the (optional) revision that should be checked out
> repository-path: the path to the (external) repository to checkout (include
> into the WC)
>
> Here is poposed extention:
>
> <dir> [-r<revision>] [--depth <requested depth>] <repository-path>
> requested depth: following the same rules as the --depth parameter for other
> svn commands.
>
> So
> <dir> --depth infinity <repository-path>
> will behave the same as without the depth parameter
>
> Another (but not so easy to implement) feature was:
> allowing svn:external to include the contents of another repository path not
> only into a subdir of the dir it is defined in.
> Something like:
> { <dir> | .} [-r<revision>] [--depth <requested depth>] <repository-path>
> So using:
> . --depth files <repository-path>
> will include all files inside the given repository-path into the WC dirs
> where this external is defined.
> This kind is hard to implement, because a commit must know if a file inside
> the dir is part of the current repository or of the 'included' one.
> So there are lot of situations where this isn't easy to detect.
>
> A third additional feature was to allow some 'inclusion'/'exclusion' pattern
> <dir> --depth infinity [-I <pattern>] [-E <pattern>] <repository-path>
> pattern: a file pattern that must be matched to inlcude/exclude any file
> that matches it
> This is a bit easier to implement then the 2. feature, but still may result
> in some problems at commit.
>
>
> So for the first step, I thing the first extension (additional --depth
> parameter to externals) should be sufficient.
> ... and very easy to implement
>
> BTW.: at the moment I am not shure how an external works when used together
> with a --depth paramter at checkout !?!
> - Will an external be checked out whith the same depth value as it's parent
> ?
> - Is an externals always processed or is it processed only if the depth is
> infinity or immediates or even on files, but not on empthy ?
>
>
>
>
>
> #####################################
> "Karl Fogel" <kfogel_at_red-bean.com> schrieb im Newsbeitrag
> news:87abgoxw0j.fsf_at_red-bean.com...
> I think the feature you're looking for is known as "client viewspecs",
> and was proposed by David James in this message:
>
> http://svn.haxx.se/dev/archive-2006-07/0624.shtml
>
> We haven't implemented them yet; see the rest of the thread for
> discussion, including http://svn.haxx.se/dev/archive-2006-08/0004.shtml.
>
> Best,
> -Karl
>
> "G.Neiß" <g.neiss_at_plarad.de> writes:
>> I like to include only the top level directory of another repository path
>> into a working copy.
>> I have read about the new (V 1.5.) feature of sparse directories and
>> belive
>> that what I need.
>> I search for this here and inside the doc, but it seams that can't be
>> done,
>> yet !?!
>>
>> Just to explain what I try to do:
>>
>> There is a repository of a current project:
>>
>> trunk
>> development
>> ...
>> customers
>> CD_Content
>> maintenance
>> parameter
>> special parameters
>>
>> Inside of 'CD_Content' for customers there should be included the
>> 'parameter' dir of maintenance, but NOT 'special parameters'.
>> This may be done by an checkout command with --depth file for the dir '
>> maintenance/parameter', but how to setup an svn:externals for
>> 'customers/CD_Content' that will check out only parameter into CD_Content
>> ?
>>
>> If this isn't possible yet, I higly reqeuset such a feature.
>> The excample given above is just a simple one.
>> I try to avoid having 'physical copies' of such files (because there is
>> always a change that something was forgotten when update is needed).
>>
>> Another thing is the ability of 'inlcuding' only 'some' files into another
>> dir.
>> In the above example it may be that almost all files from 'paramter'
>> should
>> be included, but not all.
>> This might be done by an svn:externals, that refers to the actual
>> directory
>> (instead of a subdir) and a special file in another path.
>>
>> I hope it's clear, what I try to do.
>>
>>
>>
>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
>> For additional commands, e-mail: dev-help_at_subversion.tigris.org
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: dev-help_at_subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-07-15 17:44:51 CEST