You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@subversion.apache.org by Ro...@logitech.com on 2006/11/03 01:20:18 UTC
Request/Proposal for Folder Cloaking
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.
Re: Request/Proposal for Folder Cloaking
Posted by Ryan Schmidt <su...@ryandesign.com>.
On Nov 3, 2006, at 14:01, Thomas Harold wrote:
> Let's go with the simple case and say that a developer is working
> on project A, B, D and F for a particular client. In order to make
> life simple, they would cloak C, E and G so that they could do a
> "get latest" (similar to "svn update") at the customer level which
> would then update their local working copy for all 4 projects.
>
> In the SVN world, they have to individually do updates separately
> on A, B, D and F project folders, or simply bring down projects C,
> E and G as well. (Or they could write a batch file to do "svn up"
> in each project folder...)
>
> It's always been a client-side setting (developer B won't want the
> same cloaks as developer A) in the VSS world. It's more of a
> convenience feature then part of the development process, but it
> makes working with large and complex repositories a lot easier.
>
> I can envision that some users would even like the ability when
> doing a checkout to say "cloak all sub-folders by default". Then
> they can pick and choose which folders to bring down locally. (But
> that's a "far out" use case and not very typical.)
Sounds like the feature Subversion calls "non-recursive checkouts".
http://subversion.tigris.org/issues/show_bug.cgi?id=695
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request/Proposal for Folder Cloaking
Posted by Thomas Harold <tg...@tgharold.com>.
Jeremy Pereira wrote:
> Unfortunately, it's not glaring at me. What would this feature be for?
Glaring might be overstating it a bit. The typical use case where
cloaking came in handy was larger project structures where a user really
doesn't want or need all of the repository downloaded to their hard
drive. In VSS land, you typically created a single repository for the
entire development team, then had sub-folders for each project (possibly
with another layer above that to group projects by client).
Let's go with the simple case and say that a developer is working on
project A, B, D and F for a particular client. In order to make life
simple, they would cloak C, E and G so that they could do a "get latest"
(similar to "svn update") at the customer level which would then update
their local working copy for all 4 projects.
In the SVN world, they have to individually do updates separately on A,
B, D and F project folders, or simply bring down projects C, E and G as
well. (Or they could write a batch file to do "svn up" in each project
folder...)
It's always been a client-side setting (developer B won't want the same
cloaks as developer A) in the VSS world. It's more of a convenience
feature then part of the development process, but it makes working with
large and complex repositories a lot easier.
I can envision that some users would even like the ability when doing a
checkout to say "cloak all sub-folders by default". Then they can pick
and choose which folders to bring down locally. (But that's a "far out"
use case and not very typical.)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request/Proposal for Folder Cloaking
Posted by Jeremy Pereira <je...@jeremyp.net>.
On 3 Nov 2006, at 01:20, Rohit_Singh@logitech.com wrote:
>
> Hi all,
>
> 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.
>
>
Unfortunately, it's not glaring at me. What would this feature be for?
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Re: Request/Proposal for Folder Cloaking
Posted by Duncan Murdoch <mu...@stats.uwo.ca>.
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