[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

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

From: Les Mikesell <lesmikesell_at_gmail.com>
Date: Tue, 21 May 2013 14:53:10 -0500

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
Received on 2013-05-21 21:53:43 CEST

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.