On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick <andrew.reed...@cbeyond.net> wrote: > > I don't think true renames will necessarily fix the problem. Conceptually, > the problem is that the parent dir components of a branch/tag are > superfluous, e.g. given "svn://server/repo/path/to/project1/branches/1.0", > the "svn://server/repo/path/to" and "branches" path components are > useless/meaningless to the average user.
Well, no. If I copy something from /proj1/branches/dev/branch001 to /proj1/branches/qa/branch001 or on to /proj1/branches/prod/branch001 it isn't meaningless even though at the time of the initial copy and possibly forever the contents are identical. 'Meaning' is imposed by the user, not the tool. > However, these superfluous dir components are visible to the client, which > means they're accessible by, and thus modifiable by the client. Which makes > them superfluous *and* dangerous. No, it makes them useful. > The client should only see and work with "--project project1 --branch 1.0", > e.g. "svn co --project project1 --branch 1.0" to checkout a branch. That's sort of like saying filesystems shouldn't have subdirectories so users don't get confused... Some people might even believe that. > It's about presentation. Keep the superfluous dir components internal and > hidden from the average user. We've already seen a move towards information > hiding with the'^' syntax that hides the server component. This would be the > logical progression. It's about organization. And letting you arrange your own conventions to match your processes. -- Les Mikesell lesmikes...@gmail.com