On 7/1/06, Martin Hauner <firstname.lastname@example.org> wrote:
> 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,
> 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
(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: email@example.com
For additional commands, e-mail: firstname.lastname@example.org
Received on Sat Jul 1 12:56:34 2006