[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: Tue, 19 Feb 2008 20:03:29 +0100

David Glasser wrote:
> On Feb 19, 2008 1:04 AM, Michael Haggerty <mhagger_at_alum.mit.edu> wrote:
>> Karl Fogel wrote:
>>> Steinar Bang <sb_at_dod.no> writes:
>>>> But one thing I've never understood, is why they are "branches by
>>>> convention". You guys have a very flexible metadata system, no? So why
>>>> not put a property on the top dir of a branch or a tag, saying that's
>>>> what it is?
>>> We might someday, but we weren't sure (right now) what we'd do with
>>> that. One of the nice things about a flexible metadata scheme is that
>>> you don't have to design all your features at once :-).
>> I've thought that it would make sense to add a property to the trunk
>> directory that indicates "this is a project root directory" (in the
>> sense that it is the root of a source code tree, typically the level
>> that users check out). The property would help scripts orient
>> themselves. Moreover, it would automatically get propagated when trunk
>> is copied to make a tag or branch, making it obvious (with no more work)
>> that *those* are also project root directories.
>> The point of such a property would mostly be to serve as a line of
>> demarcation between the project/trunk/tags/branches namespace
>> interesting in the SCM world and the filename namespace interesting for
>> working copies, build tools, etc.
>> If there were a standard convention and name for such a property, then
>> tool builders might start using it.
> Of course, finding such properties, noticing updates to them, etc, is
> not actually trivial under the svn model (see the incredible amount of
> effort required to make mergeinfo inheritance work, and it still has
> some holes).

Precisely my point, and one of the things I ranted about in this thread
two months ago: the client shouldn't be doing the server's job.

-- Brane

To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-02-19 20:24:45 CET

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.