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

Re: Reality check

From: Branko Čibej <brane_at_xbc.nu>
Date: 2007-12-15 03:19:58 CET

Hyrum K. Wright wrote:
> Karl Fogel wrote:
>
>> Branko Čibej <brane@xbc.nu> writes:
>>
>>> IMNSHO, we should first support the mainstream CM paradigm, then worry
>>> about edge cases such as yours. Having the branch and directory
>>> namespaces conflated is sexy for small projects but horror on
>>> moderate-sized ones. And on large projects, you end up inventing branch
>>> namespace hierarchy where the tool doesn't support it.
>>>
>> I'm all for distinguishing formally between branches and copies, but
>> I'm not at all convinced it's problematic to have branches live in the
>> directory hierarchy. Kind of the opposite: I've liked it so far!
>>
>
> I have similar feelings. In working on some of the auditing code, I've
> often thought "gee, if I could only tell if this copy is a branch or a
> true copy." Having branches in directory hierarchy is very useful,
> especially when browsing them using mod_dav_svn and my favorite web
> browser. But the extra branch v. copy metadata would be useful.
>
>
Let's distinguish between "looking at the repository with a web browser"
and "accessing the repository via an HTTP-ish connection." The cases are
orthogonal.

For the "looking at" part, try as I might, I can't see what's wrong with
having a separate repository-browsing server. The fact that you can
browse through a Subversion repository using mod_dav_svn is a wart
(which I admit I helped perpetuate). It gives the false impression of
being useful while at the same time giving the false impression that SVN
can't live without conflated branches and directories.

It's in fact a lot better to use dedicated severs like ViewVC (or hgweb,
hello competition) that can interpret what it sees in the repository and
has lots of bells and whistles. And keep the actual repository-access
server lean fast.

-- Brane

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Dec 15 03:20:35 2007

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

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