You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Martin Hauner <ma...@gmx.net> on 2006/07/01 10:20:39 UTC
Re: Tags -> repository configuration
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 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.
/trunk
/tags/t1
/tags/t2
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.
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?
--
Martin
Subcommander 1.0.0 - http://subcommander.tigris.org
a cross platform Win32/Unix/MacOSX subversion GUI client & diff/merge tool.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Michael Sinz <Mi...@sinz.org>.
On 7/1/06, Martin Hauner <ma...@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
Re: Tags
Posted by Julian Foad <ju...@btopenworld.com>.
Martin Hauner wrote:
> I think this all about easier tag handling, not if it is broken.
Absolutely. Well said, Martin!
Many users go a long way before they encounter any situation where such things
as mixed-rev tags are useful. They have a real concern:
Subversion's tagging concept is far more powerful than we
need or want in most projects, and the "svn" command-line
interface to it is far too cumbersome for our simple needs.
We developers have to stop saying:
Subversion's tagging concept and interface provides the power
that some people need. We won't replace it with a simpler one,
and we don't want two separate concepts, so just use it!
Think about it this way: if we were designing an independent command-line
client, with this powerful "tagging" as a feature, what interface would we
choose? Surely not exactly what "svn" provides.
It is our job as developers to reconcile the needs of many users for a simple
interface with the needs of some users for more power and flexibility, in an
elegant way.
Make the simple tasks easy, and the complex tasks possible!
We CAN do that; we just need to work out how. What we need to do:
1) Analyse the ways in which users want to use tags: both the operations they
want to achieve and the command-line syntax they are accustomed to using (in
CVS for example). Move away from discussing it again each time someone asks
about it. Instead, document the current position and the requirements that
have been expressed and get each new person to read and then update that
document after asking any questions that are not already addressed. (Do we
have a Wiki where we could put that?)
2) Write some advice (maybe in a FAQ entry) on how to most conveniently do
those simple things using svn. This might, for example, recommend setting up
environment variables, command aliases, etc. It should also give a link to a
detailed explanation of how Subversion's tagging concept compares with CVS's
tagging concept.
3) Write and distribute a helper tool that provides most of the simple tag
operations that users want (as determined in (1)). It probably won't be able
to do everything that we could make "svn" support natively, but that doesn't
matter initially.
4) Design an enhancement to "svn" (and the libraries if necessary) to provide a
simple interface for using simple tags while keeping the flexibility that we
have now.
Finally, in this discussion, whenever we say something like "you can't do that
with tags", take care to be clear what tagging concept we are talking about.
At pretty much opposite ends of the spectrum are "tags as copies" (Subversion's
tagging concept) and "tags as revision aliases", and there are possibilities in
between. We want to provide an interface that supports both or a range of
concepts, while being built on an implementation that uses the "tags as copies"
concept.
- Julian
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Danny van Heumen <da...@hccnet.nl>.
Martin Furter wrote:
>
>
> On Wed, 12 Jul 2006, Danny van Heumen wrote:
>
> OK, I have a server with wiki running now, needed a bit more time, sorry.
> It is on a temporary IP now, have to get a few more daemons running
> until I can replace the old box... (the name won't change, only the IP)
Nice :)
> It is: http://svn.borg.ch
Yup
> Feel free to add some stuff, you just have to create an account first.
My first thought was to begin with the definition of a Tag, because
we've already got that. Following with a definition of a Branch (haven't
done that yet.) And after that - I'm not sure yet - something like
pros/cons or scenarios + repos layouts or so.
OK. I have registered.
Will add some stuff, but it could take a day or so, because it's quite
hot in here (+/- 33 degrees Celcius) so I'm not as active as I used to be :P
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Martin Furter <mf...@rola.ch>.
On Wed, 12 Jul 2006, Danny van Heumen wrote:
> Martin Furter wrote:
>> Maybe I find some time to setup my new server, maybe on a different IP
>> for now. Then we'll have a wiki and svn...
> That would be nice.
OK, I have a server with wiki running now, needed a bit more time, sorry.
It is on a temporary IP now, have to get a few more daemons running until
I can replace the old box... (the name won't change, only the IP)
It is: http://svn.borg.ch
Feel free to add some stuff, you just have to create an account first.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Danny van Heumen <da...@hccnet.nl>.
Martin Furter wrote:
> Right. I was talking about different types of configs, like subdir for
> svn, tortoise, ...
> Project configs should be stored somewhere in teh project directory.
Ah ok :)
> We should also answer the question 'What is a branch?'. It's mostly the
> same answer as for tags.
True (I had this planned, but I haven't had the time yet ;) )
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Martin Furter <mf...@rola.ch>.
On Wed, 12 Jul 2006, Danny van Heumen wrote:
> Martin Furter wrote:
>> I like the idea to group things into subdirectories. That leaves space
>> for config files of other tools.
> The only problem is that people often play around with only one project.
> And it seems kind of overkill to create groups when there's only one
> project.
Right. I was talking about different types of configs, like subdir for
svn, tortoise, ...
Project configs should be stored somewhere in teh project directory.
> As you've seen I've posted the 'What is a tag?' thread. I think it's
> quite clear now what we expect from a tag. Maybe the definition isn't as
> accurate as we would like, but I think everyone understands. This would
> be one thing we could put in the Wiki... It would be a good start.
We should also answer the question 'What is a branch?'. It's mostly the
same answer as for tags.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Danny van Heumen <da...@hccnet.nl>.
Martin Furter wrote:
> I like the idea to group things into subdirectories. That leaves space
> for config files of other tools.
The only problem is that people often play around with only one project.
And it seems kind of overkill to create groups when there's only one
project.
> Maybe I find some time to setup my new server, maybe on a different IP
> for now. Then we'll have a wiki and svn...
That would be nice.
I don't have an on line server available so easy, and to put this stuff
on my home server isn't that smart. I'm playing around quite a lot, so
it could disappear in an instance :P
As you've seen I've posted the 'What is a tag?' thread. I think it's
quite clear now what we expect from a tag. Maybe the definition isn't as
accurate as we would like, but I think everyone understands. This would
be one thing we could put in the Wiki... It would be a good start.
In the other threads I'm following the replies of Håkon and others. If I
understood correctly he knows now why we don't want to change
subversion's tagging/branching system, so he's now also looking for a
solution in something like a wrapper or wizard.
So I think we're kind of on the same line now :D
> Btw: I saw in the other thread something we might have missed: Creating
> a tag or branch from a possibly modified working copy.
Yeah. I got that from a thread from a few months ago.
At the moment I'm quite occupied with other things (non-subversion).
After that's all done I will have some more time available for this.
(I'm certainly not backing off (yet) ;) )
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Martin Furter <mf...@rola.ch>.
On Fri, 7 Jul 2006, Danny van Heumen wrote:
> Erik Kline wrote:
>> So if I read all this (and the previous thread) correctly there seems
>> to be interest in collecting a best practices standard for holding
>> configuration information relevant to:
>>
>> 1. repository layout (and perhaps other svn properties not yet
>> metioned/thought of)
> Yes exactly. I think for the most part the problem is that the
> configuration was not made with a location for tags and branches in
> mind. And this is simply because you don't have to with other RCS.
>
>> 2. layers used on top of svn (wrappers, IDEs, et alia?)
> This is a way of supporting those admins with their first svn repository
> as I see it. (That's also the way I want to work out some things that
> I've discussed somewhere down this thread.)
>
>> This would be completely optional and not even a part of svn core
>> code, but rather a documented, extensible, standard/recommendation
>> that contrib tools and "third party" apps could gradually start to
>> support.
> Well it's not THE way, but it is a way that keeps the more advanced
> features of SVN in mind.
>
> This is mainly why I would like to document all arguments for and
> against subversion's tagging/branching and why I want to create some
> example repository layouts.
>
> I'm working on both at the moment, but I'm planning to post a message to
> the list soon that's a list of quotes/statements with a response from a
> CVS (and other RCS) user and a SVN user.
> If we know what people disagree on, we can find solutions for those
> disagreements.
Nice :)
>> Does that sound somewhat correct?
> I think so, at least it's in line with what I am thinking ;)
>
>> I'm imagining some sort of document (wiki?) that recommends various
>> filenames and formats for svn config things under some well-known
>> repository url (e.g., 'BASE_REPO_URL/_config/svn/...'), and other
>> projects can spec their own formats under an equally
>> well-known/guessable, yet entirely related, repository url (e.g.,
>> 'BASE_REPO_URL/_config/{"subclipse",other_project,company_name,"site"}/...'
>> ).
> Well, we've discussed something like this further down in the main
> thread (not in "Re: Tags -> repository configuration")
I like the idea to group things into subdirectories. That leaves space for
config files of other tools.
>> But maybe I've wandered off into left field on my own...
> Not yet, but I do think it's important that we document the facts first,
> before rushing on to all kinds of tools with configuration etc.
> If we don't document the facts now, there will probably be a new
> discussion next month :D
Maybe I find some time to setup my new server, maybe on a different IP for
now. Then we'll have a wiki and svn...
Btw: I saw in the other thread something we might have missed: Creating a
tag or branch from a possibly modified working copy.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Danny van Heumen <da...@hccnet.nl>.
Erik Kline wrote:
> So if I read all this (and the previous thread) correctly there seems
> to be interest in collecting a best practices standard for holding
> configuration information relevant to:
>
> 1. repository layout (and perhaps other svn properties not yet
> metioned/thought of)
Yes exactly. I think for the most part the problem is that the
configuration was not made with a location for tags and branches in
mind. And this is simply because you don't have to with other RCS.
> 2. layers used on top of svn (wrappers, IDEs, et alia?)
This is a way of supporting those admins with their first svn repository
as I see it. (That's also the way I want to work out some things that
I've discussed somewhere down this thread.)
> This would be completely optional and not even a part of svn core
> code, but rather a documented, extensible, standard/recommendation
> that contrib tools and "third party" apps could gradually start to
> support.
Well it's not THE way, but it is a way that keeps the more advanced
features of SVN in mind.
This is mainly why I would like to document all arguments for and
against subversion's tagging/branching and why I want to create some
example repository layouts.
I'm working on both at the moment, but I'm planning to post a message to
the list soon that's a list of quotes/statements with a response from a
CVS (and other RCS) user and a SVN user.
If we know what people disagree on, we can find solutions for those
disagreements.
> Does that sound somewhat correct?
I think so, at least it's in line with what I am thinking ;)
> I'm imagining some sort of document (wiki?) that recommends various
> filenames and formats for svn config things under some well-known
> repository url (e.g., 'BASE_REPO_URL/_config/svn/...'), and other
> projects can spec their own formats under an equally
> well-known/guessable, yet entirely related, repository url (e.g.,
> 'BASE_REPO_URL/_config/{"subclipse",other_project,company_name,"site"}/...'
> ).
Well, we've discussed something like this further down in the main
thread (not in "Re: Tags -> repository configuration")
>
> But maybe I've wandered off into left field on my own...
Not yet, but I do think it's important that we document the facts first,
before rushing on to all kinds of tools with configuration etc.
If we don't document the facts now, there will probably be a new
discussion next month :D
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Erik Kline <ek...@google.com>.
On 7/3/06, Mattias Engdegård <ma...@virtutech.se> wrote:
> Steinar Bang <sb...@dod.no> writes:
>
> >Another problem is that subversion UIs, such as eg. subclipse, have to
> >guess at the directory structure chosen for the tags if _they_ would
> >like to offer a friendlier interface to tags and branches
>
> To expand on this: While subversion elegantly allows tags and branches
> to be organised hierarchically, there is no way a tool can infer this
> from the layout (consider "/frobulator/tags/releases/7.2" where the
> tag is "releases/7.2").
>
> Local conventions is the only recourse here, like adding magic
> properties to directories in tags/ and branches/, but this reduces the
> commonality that makes standard tools useful - no good if everyone
> have to write their own log browser, IDE plug-in, etc.
So if I read all this (and the previous thread) correctly there seems
to be interest in collecting a best practices standard for holding
configuration information relevant to:
1. repository layout (and perhaps other svn properties not yet
metioned/thought of)
2. layers used on top of svn (wrappers, IDEs, et alia?)
This would be completely optional and not even a part of svn core
code, but rather a documented, extensible, standard/recommendation
that contrib tools and "third party" apps could gradually start to
support.
Does that sound somewhat correct?
I'm imagining some sort of document (wiki?) that recommends various
filenames and formats for svn config things under some well-known
repository url (e.g., 'BASE_REPO_URL/_config/svn/...'), and other
projects can spec their own formats under an equally
well-known/guessable, yet entirely related, repository url (e.g.,
'BASE_REPO_URL/_config/{"subclipse",other_project,company_name,"site"}/...'
).
But maybe I've wandered off into left field on my own...
-Erik
Re: Tags -> repository configuration
Posted by Mattias Engdegård <ma...@virtutech.se>.
Steinar Bang <sb...@dod.no> writes:
>Another problem is that subversion UIs, such as eg. subclipse, have to
>guess at the directory structure chosen for the tags if _they_ would
>like to offer a friendlier interface to tags and branches
To expand on this: While subversion elegantly allows tags and branches
to be organised hierarchically, there is no way a tool can infer this
from the layout (consider "/frobulator/tags/releases/7.2" where the
tag is "releases/7.2").
Local conventions is the only recourse here, like adding magic
properties to directories in tags/ and branches/, but this reduces the
commonality that makes standard tools useful - no good if everyone
have to write their own log browser, IDE plug-in, etc.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Steinar Bang <sb...@dod.no>.
>>>>> "Ben Collins-Sussman" <su...@red-bean.com>:
> I agree. I think the only "problem" we currently have with our
> tagging system is that the UI isn't so friendly.
Another problem is that subversion UIs, such as eg. subclipse, have to
guess at the directory structure chosen for the tags if _they_ would
like to offer a friendlier interface to tags and branches
Granted, most will follow the recommendations of the book
http://svnbook.red-bean.com/nightly/en/svn.reposadmin.projects.html#svn.reposadmin.projects.chooselayout
so heuristics based on them will probably work in 90% of the cases.
But relying on heuristics still feels fragile, somehow.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags -> repository configuration
Posted by Ben Collins-Sussman <su...@red-bean.com>.
On 7/1/06, Martin Hauner <ma...@gmx.net> wrote:
> 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 agree. I think the only "problem" we currently have with our
tagging system is that the UI isn't so friendly. It's a pain to type
long URLs when referring to branches and tags. And I think you're
right, a solution to that problem would be to encode the knowledge of
the 'structure' of the repository ... somewhere ... so that users can
access branches and tags via short names. That would be a lot less
radical of a change than redesigning our tag implementation!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org