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

Re: Request/Proposal for Folder Cloaking

From: Duncan Murdoch <murdoch_at_stats.uwo.ca>
Date: 2006-11-03 15:40:22 CET

On 11/2/2006 8:20 PM, Rohit_Singh@logitech.com wrote:
> Hi all,
>
> I'm a long time Subversion user, first time poster. I'm a HUGE fan of svn,
> but I've used Subversion long enough to know that it isn't a perfect
> version control system.
>
> IMHO, outside of Merge Tracking and Improved Rename Support, perhaps the
> most glaring need of Subversion (from a practical standpoint, of course) is
> the ability to "cloak" or "de-cloak" a folder. For those of you not
> familiar with Visual Source Safe, "cloaking" is a server side operation
> that allows the repository to exclusively filter "Get Latest" (a.k.a.,
> "Update") operations.
>
> So, for example, if I map the following directories:
>
> $/
> Foo/
> Bar/
> Uh/
>
> to the following working copy:
>
>
> D:\
> Foo\
> Bar\
> Uh\
>
> Any "Get Latest" (a.k.a. "Update") on the D:\ drive would recursively
> update the contents of the Foo, Bar, and Uh folders recursively. However,
> if we proceeded to "cloak" the Bar folder, a "Get Latest" on the D:\ drive
> would update the Foo and Uh folders recursively, but would effectively
> ignore the Bar folder and all of the children of the Bar folder. In order
> to update the contents of the Bar folder, we would have to "Get Latest" on
> the Bar folder.

I think this is related to non-recursive checkouts. If you were allowed
to check out Foo and Uh, and export Bar, you'd get the behaviour you
want. However, I think that will cause svn to complain when you try to
update D:\, because it will try to restore Bar and die when it sees a
Bar already there.

Duncan Murdoch

>>From a use-case standpoint, I envision Cloaks to be a
> Checkout/Update/Commit filter. While in VSS, cloak information was a
> function of the user and stored on the repository, I think the cloak
> information should be applied only to the working copy. In fact, I don't
> think the repository should even have direct knowledge of cloaked elements.
>
> Using an example similar to the one below, if I have the following
> repository:
>
> http://source
> /Foo
> /Bar
> /Uh
>
> associated with the following working copy:
>
> D:\
> Foo\
> Bar\
> Uh\
>
> Checkout:
>
> If I wanted to cloak Bar on checkout, I could a -cf [--cloakfile] argument.
> An example of such a file would be:
>
> + /Foo
> - /Bar
> + /Uh
>
> Any folder name preceeded by a "-" would be identified as a cloakpoint.
>
> I envision a system similar to
> Now, while in VSS "cloak" information was tied to the user, I envision a
> system
>
> ---
> Rohit S. Singh Phone: (905) 366-6164
> Software Q. A. Developer Fax: (905) 273-9789
> Logitech International S. A. Toll Free: 1-866-291-1505
> Remote Control Business Unit http://www.logitech.com/harmony
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: users-help@subversion.tigris.org

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Nov 3 15:41:10 2006

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.