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

Re: Subversion, decentralized version control, and the future.

From: B. Smith-Mannschott <benpsm_at_gmail.com>
Date: 2007-07-05 17:02:02 CEST

On 7/5/07, David Glasser <glasser@mit.edu> wrote:
> On 7/5/07, C. Michael Pilato <cmpilato@collab.net> wrote:
>
> > 1. all that flexibility makes it harder for Subversion and other third-party
> > tools to recognize and treat a directory copy as a branch. Common questions
> > like, "What tags exist?" can't be answered unless the answering system first
> > understands the policy used to denote tags in a given repository ("stuff
> > immediately under /tags"; "stuff immediately under an immediate subdirectory
> > of /tags"; ...)
>
> ... and as an extension of this, it leads directly to the whole "no
> project-wide configuration" can of worms.
>
> --dave

Wouldn't this the sort of thing properties are for? We could use a
property to record the meaning we intend the directory to have. i.e.
it's "role".

e.g. suppose we could say:

svn cp --tag SOURCE DESTINATION
svn cp --branch SOURCE DESTINATION

which would behave just like svn cp, except that it sets a property
svn:role=tag or svn:role=branch.

Perhaps the repository could even keep track of which directories
currently visible in head have an svn:role and provide some efficient
way to list them. Their history could tell us what they are tags or
branches *of*.

If we marked the directories in this way, we wouldn't have to know
policy to browse existing tags. (Only if we wanted to abstract their
creation somehow.)

Just a thought
// ben smith-mannschott

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu Jul 5 17:02:08 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.