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

Re: Tags -> repository configuration

From: Michael Sinz <Michael.Sinz_at_sinz.org>
Date: 2006-07-01 12:56:07 CEST

On 7/1/06, Martin Hauner <martin.hauner@gmx.net> wrote:
> Hi,
>
> Mark Phippard wrote:
> > [..tags..]
> > When all is said and done, the problem is that there are a large number of
> > people, myself included, that do not really think anything is broken and
> > needs to be fixed. We know it is different in some ways, but we like
> > those differences. If you can "bridge the designs" without compromising
> > what we like, then great.
>
> I think this all about easier tag handling, not if it is broken. The
> possibility to use branch and tag names as revision parameters would
> simplify branch/tag handling. Especially for the command line tool.
> If this would be possible most of the reservation with the copy-tags
> would vanish.

I believe that you are very correct - most of the suggestions seem to
be based on what the user wants for a command line and then they
backfill the mechanics to get "almost" what they want.

> I think what subversion is missing is a repository side configuration
> of a project. This is not thought out, I'm just thinking loud here:
>
> If subversion could store the repository layout for a project we could
> simply describe where a project keeps it branches and tags. It would
> simple store the branches/tags url.

Actually, this is not far off of what was discussed earlier - ways to
do short-cut names for certain common behavioral URLs. (tags,
branches, etc)

> If svn hits an -r t1 revision it could search it's tag and branch folder
> for an t1 entry and use the head revision from the resulting path.
>
> The configuration could be simply stored in the repository (maybe some
> magic hidden folder, so the configuration would be versioned too), its
> just the question where and how an svn client could retrieve it.

Also, fundamentally, repository (server) managed configuration
information is a major missing feature. One of the main ones that
keeps on biting people is the lack of centralized control of the
autoprops configuration (and per-project or per-repository control
of the same)

> I think this would also help with other features that were discussed
> before. Not that i could name one right now... ;) Weren't there a couple
> of features that never got implemented because of a missing place to
> store necessary information? Log templates? And some got implemented
> by duplicating property information on every folder?

Yes, and if I had the time (or others here, I believe) I would be working
on this. To me, this is the number one missing base technology/feature
within Subversion. Central control of configuration information on at
least a per-repository basis is a big issue.

Even more so when you look at maybe wanting to have that information
revision tracked (who made what change when).

The problem is non-trivial when we talk about how to hook it up and notice
it due to the partial trees, disconnected behavior, and external repository
links.

(Actually, I have some ideas on this but they all tend to require storage
somewhere in the user's home directory and add to the communications
overhead more than I would like)

-- 
Michael Sinz               Technology and Engineering Director/Consultant
"Starting Startups"                          mailto:Michael.Sinz@sinz.org
My place on the web                      http://www.sinz.org/Michael.Sinz
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Jul 1 12:56:34 2006

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.