Request/Proposal for Folder Cloaking -- Second Attempt

Hey,

Sorry about last night -- I accidentally sent out a draft of the message
below that I was working on. Attached below, you'll find my
request/proposal for folder cloaking in its full glory (lol).

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.

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 above, imagine 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”
(all folders would be in the “+” state by default). “Cloakpoint” folders
will be checked out with a special status in the “entries” file identifying
the folder as a cloakpoint. After generating a cloakpoint folder,
subversion will not continue in a recursive manner – i.e., it will leave
the “Bar” folder empty (except for the .svn folder).

However, “cloaked” folders should still be valid working copies, and
therefore checkout-able. Therefore, I should still be able to later check
out http://source/Bar to “D:\Bar”, even though “Bar” is a cloakpoint.

Update:

Updates to the working copy should be applied as usual – but stop at
cloakpoint folders. Thus, an update on D:\ would update the children of
“Foo” and “Uh”, but would ignore “Bar” and associated subtrees.

Updates can be applied directly to cloakpoint folders themselves. Using
the example above, if I wanted to update “Bar”, I could call “svn up
D:\Bar” to update on “Bar”.

(Subversion should likely provide a flag to override the cloakpoint
structure, like “svn up –ic” or “svn up –ignorecloakpoints”).

Commit:

Just like updates, commits should be filtered by cloakpoints. So a commit
on D:\ would generate a list of files that exclude any affected children of
“Bar”.

As with updates, cloakpoints can be committed directly. So while “svn ci
D:” would ignore any local modifications to “Bar”, “svn ci D:\Bar” would
allow for modifications to /Bar to be sent to the repository.

(Again, a flag should be used to override the cloakpoint structure, like
“svn ci –ic” or “svn ci –ignorecloakpoints).

Cloak/De-cloak:

Any working copy folder can be cloaked or de-cloaked.

Potential Issues:

-> Invalid cloakfile -- Subversion should detect any issues with the
cloakfile (i.e., folders not found in the expected checkout), and should
post a warning to the user.
-> Deletes -- I don’t this will really be a problem. If the cloaked folder
is deleted on the repository, it should be deleted on an update to its
parent.
-> Renames -- Since renames are really two part operations, a copy and
delete, what happens with a cloak mapping on my end? Say a user renames
“Bar” to “Bar2” on the repository, what happens on my working copy where
“Bar” used to be cloaked when D:\ is updated? Should I see any change?
Should I get a “Bar2”? And if so, should “Bar2” be cloaked? (Probably yes
to all, but it’ll be tricky without a single rename operation).
-> Switches -- Should switches be treated like updates (i.e., Don’t recurse
into subfolders)?

I’d like to apologize if people have already been discussing cloaking in
other threads – my search on dev@subversion.tigris.org only revealed the
following thread on the subject:

Is this not a function of the Versioned Modules? It sounds to me that
an SVN module is a list of directories. You set up a module that has
the directories the specific user needs, and SVN ignores the other
things in the tree. I suppose this is rather a mirror image feature
from what you describe as "cloaked" directories... but maybe it is
what you are looking for. (I have not used modules in SVN, so this
is just a thought.)

>From the book:

Unlike CVS, a Subversion working copy is aware that it has checked out
a module. That means that if somebody changes the definition of a module,
then a call to svn update will update the working copy appropriately.
Subversion defines modules as a list of directories within a directory
property: see the section called "Externals Definitions".

---
Kevin R. Bulgrien
Please let me know what you think.
Thanks!
---
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