On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick
<[email protected]> 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
[email protected]
