Re: Subversion Doesn't Have Branches aka Crossing the Streams aka Branches as First Class Objects?

On Tue, May 21, 2013 at 2:27 PM, Andrew Reedick
<Andrew.Reedick_at_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
     lesmikesell_at_gmail.com