You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Mark Phippard <ma...@softlanding.com> on 2006/07/01 00:51:02 UTC
Re: Tags
hakon@ion.no wrote on 06/30/2006 07:22:13 PM:
> > On 6/30/06, hakon@ion.no <ha...@ion.no> wrote:
> > What's confusing here is that you're offering a solution to something,
> > but nobody seems to understand what that something is. What's the
> > problem you're trying to solve? Before you can propose technical
> > solutions, you need to persuade us that there's a problem with
> > subversion's current tagging system.
>
> I want to simplify and enhance tagging in Subversion. I also would like
to
> make Subversion tagging feel more like other version control systems',
> because I believe the current scheme is unnecessary difficult to use and
> understand.
>
> Here is my list of possible improvements to the Subversion's tagging
scheme:
>
> 1. The user should not need to be bothered with _where_ the tag will be
> stored.
>
> 2. The Subversion 'tag concept'* should be the same as other VCS', as
the
> Subversion concept does not add any value and confuses newcomers.
These sorts of items are classic examples of where the answer seems like
you would be best served by looking at another version control solution.
The things you do not like are essential parts of the Subversion design.
They are not flaws, they are intentional. Personally, I love this design
and think it is extremely intuitive and easy to understand.
> 3. In line with (2), commands like 'svn up -r v1.0' should work as
expected.
This has been mentioned before. Thus far a design has not emerged that
was worth implementing. There are techniques using shell variables that
can work. Not that that is the ideal solution, just that the proposed
designs have not been better enough to make it worth doing.
> 4. Subversion should 'know' of tags. E.g. look at what Subclipse have
done
> because Subclipse knew about the tags, and realise that Subversion
should
> support this natively. (Now the user had to locate the tags directory
for
> Subclipse.) In an earlier email I was telling about a possible 'svn
> taglist' command that displays "TAG REVISION AUTHOR DATE" for all tags,
> which is excactly the command-line version of one of the features of
> Subclipse.
It would be nice if the command line could do some of the similar things
we are doing in Subclipse, but to be honest, the Subclipse solution can
work because the project/repository structure within Eclipse is very
predictable and consistent. It would be a lot more difficult for this to
work "in general". There are some changes to SVN properties that have
been discussed that could make this more viable, but the design has been
tricky to nail down.
> 5. Subversion should get a 'tag' command to make the intention clear.
(In
> its simplest form, it could be another alias for 'copy'.)
The Subversion developers have been very much against subcommand bloat.
Adding "tag" as an alias for copy would be a terrible idea because if a
good design for tag improvements surfaces in the future the subcommand
would not be available.
> 6. Subversion should provide a more compact syntax for tagging. Say 'svn
> tag -r REVISION TAG', or 'svn tag --force NEWREVISION' to update an
> already set tag, or 'svn taglist' for displaying tags.
These things can be done with shell variables and a lot of other
techniques.
> *) The Subversion concept of a tag is that it is a directory (in HEAD).
> While other VCS uses a concept of tags which is a revision number (or a
> path and a revision number).
>
> The proposed solution of putting tags as special properties solves all
of
> them.
It doesn't, and without major API changes to properties it couldn't work.
Your proposed solution was not very well thought out. Look at the Apache
repository at http://svn.apache.org/repos/asf. There are 39 different
projects. How could you store all of the tags in revision 0 of the
repository root and have the feature work and have meaning? Doing
something like Subclipse where the properties are stored as versioned
properties within the repository would work conceptually but there are a
lot of real API hurdles to overcome before that could be done. It might
be worthwhile to head further down this path and work up a real design,
but I have a feeling that to implement this "tag" feature you would have
to dive into large thorny areas like changing how properties work.
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.
Mark
---------------------------------------------------------------------
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
Re: Tags -> repository configuration
Posted by Martin Hauner <ma...@gmx.net>.
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
Posted by ha...@ion.no.
>> Would you care to mention the difficulties with properties? All I can
>> think of is:
>> 1. It is not possible to commit changes to single property on a
>> file/directory.
>> 2. It is not simple to search properties based on their values. Or sort
>> the properties based on their values.
>
> These are the main issues with using properties as I see them:
>
> 1) The property needs to be available in the WC to be used. If the tag
> property is just on a specific folder, and you checked out some
> sub-folder, then now you don't have the property available to be used.
A 'tag' is supposed to tag a 'project' (the trunk, a branch or once the
working copy of some committer). If a developer is not working with that
project, but has checked out a subtree, then the developer cannot
reasonably assume the 'tag' to work optimally. We might make it fail, or
there might be a performance hit.
Users comming from other VCSs are used to working with projects, and so we
cover those Use Cases 100%. For Subversion oldtimers, well they are mostly
satisfied with the current scheme. So in any case this cannot be a
showstopper.
> This is why the feature works in Subclipse, because there are very
> specific folders that an Eclipse user will check out. Setting the
> property on every folder is unmanageable.
I agree.
I believe we should put properties on the trunk directory, all branch
directories and all tag directories, and the property should explicitly or
implicitly reference the same 'project'.
Whether a directory needs to be marked as the 'project' directory, I do
not know yet.
Subclipse could just check for a trunk, branch or tag, and if found it
would be able to find all branches and tags through the 'project'.
> The solution we have talked
> about is something called "inherited properties", but there are some messy
> issues to deal with to do that.
If the user checks out a branch, and runs "svn diff -r version-1.0" deep
inside the tree, then what's wrong with walking up the directory tree
until we find the 'project'? There may be a slight performance hit by
checking for a specific property on every directory, does anybody know how
much? 100ms at most? In any case, I cannot believe this would be
significant, as most users will be close to the 'project' when running
such commands.
> 2) You cannot set a property directly on a URL. This is technically
> feasible, it just has not been allowed or exposed. In this case, since
> you'd only want to append to the existing value, maybe it would be a
> capability that could be added?
>
> 3) Since properties are versioned, they require a commit. This might be
> the sort of thing that could be combined with #2 so that if we had a
> special svn tag command, it could under-the covers, to the copy and the
> update of the tag property in a single atomic operation.
I agree with your suggestion.
> 4) Once you have properties they are not easily searchable. For this
> particular feature, I am not sure how significant a problem that is.
This should not be a problem for tags.
> 5) As others have pointed out, a single property value cannot easily
> express a complex mixed-revision tag.
Agreed, but this is not a problem of 'properties' alone, but with the fact
that Subversion-like tags is a snapshot of (any) historic tree, even trees
not otherwise in the repository, and generally the simplest way to
represent such a snapshot is by storing the whole tree.
There are too many people thinking we should continue with the current
Subversion-like tags, and that's fine with me. That just means the
solution needs to be a little different than what I have suggested in my
earliest emails.
And so a 'tag' should still be a Subversion-like tag, and the 'tag' is a
directory containing a snapshot of some historic tree. We should still set
a property on the tag directory, notifying clients that this directory is
a tag and that it relates to a specific 'project'.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Martin Furter wrote:
> ...
> Additionally we have groups containing libraries, communication
> software, shared code, 3rd party software and one with misc stuff mostly
> for internal use.
It seems like a very useful layout for very large repositories. I don't
think this is the kind of layout we should implement at first. But
that's why I would like to have a wiki, to gather all ideas and best
practices.
> Ofcourse there are many ways to group projects.
> In our old RCS-like VCS we had the groups server and client software
> (and a few others) but most of the projects were in client-software so
> we used the opportunity to rearrange the projects when we switched to subversion
> two years ago.
> It was pretty hard to find the 'right' layout but I guess we did a
> pretty good job, there's only one project which I would put into a
> different group today.
Yeah I'll bet :)
> Yes, same here.
>
> But every game has its own rules... ;)
>
> About 3 1/2 years ago I started playing with subversion, just to share
> some sourcecode with a friend. About 6 month later the game had to be
> expanded to new territory... so I converted 2 of our projects into SVN.
> About a year later when we imported all of our projects I had 4 SVN
> repositories, but we wanted all of our code in just one repository. So I
> was forced to merge them somehow. And that is why svndumptool exists today.
Hmmm... well... my experiences aren't that exciting to tell. I've
started playing with around with Subversion about 2,5 years ago. Because
I had read a lot about CVS but couldn't figure it out fast enough :)
When I was looking around a bit for available VCS I found Subversion,
and I was sold immediately :D.
I've used it for my own projects and for during school projects ever
since. Luckily I've managed to convince my group every time we had a
project ;)
I've been playing around quite a lot with SVN since I had discovered it.
Not only for basic use ('cause all my use is quite basic) but also with
testing merging, creating branches, etc.
> I guess the first question the wizard should ask is:
>
> What do you want to do?
> 1. Play around with a toy repository.
> 2. Think about the layout for real repositories.
Do we want an option to 'play around?'... Couldn't we just assume one
wants to set up a layout for a real repository? Because even people who
are just playing around, want to play around with a real repository.
In essence we only want to show the user how to set up a repository in a
way that all features (tags/branches/...) are easily usable and the
layout is sufficiently extensive that it can store several projects.
> Right.
> But I guess if the administrative part of the tool is really good the
> rest will become simple automatically.
Yep that's right. (At least I hope it is ;) )
Looking at it from another perspective: If the administration is too
extensive and exhaustive it'll be hell for a starting repo admin.
Especially one who is really experimenting with SVN's possibilities.
> Though, that config file in the repository needs a few more thoughts.
> If we put it into a directory (just containing that config file) we can
> checout that dir into the config area of the wizard. If the file is in
> the root directory of the repos we are forced to use the subversion API.
> (not that I am against using it, it is just a dependency the tool will
> have)
Hmmm... indeed.
> I was thinking about a commandline tool checkout and multiple
> repositories. The user needs a way to specify which project of which
> repository he wants to checkout, and there may be projects with the same
> name in different repositories (or even in the same repos).
>
>> The wizard shouldn't limit the user in it's possibilities, only guide.
>> And I know that's going to be hard, but at least keep it in mind ;)
>
> Yes, that's why I proposed to specify trunk tags and branches for each
> project instead of a layout which must apply to all projects in teh same
> repository.
> But maybe that's not enough: What about support for things like
> tags/releases, tags/release-candidates, ... ?
I think this is the very reason why we shouldn't think this far ahead
yet. Also because we want to start with easy examples for those who
don't have a clue about the layout yet.
> I think a wiki would be nice for storing the ideas/specs/...
> But for discussing things either a mailing list or a forum would be better.
Does someone have a wiki available? I could set one up, but It's only on
my home server so this wouldn't be very fast ;) And I thought there was
already a subversion (or so) wiki running. (Don't know where though.)
For discussions I really like a mailing list, because if I don't get
triggered I could probably lose attention if I'm a bit busy with my work.
Setting up a mailing list isn't much of a problem because I have a
mailman mailing list running on my own server at home.
And if no better opportunity arises I can set up a wiki too.
> We could also use a SVN repository for storing the ideas and continue
> discussing here.
SVN? Couldn't we use a CVS repository? Subversion's tags and branches
really suck :P ;)
> I just don't know how long we can continue spamming this list until we
> get kicked ;)
Well... that's my point exactly :D
>> I think it is very important that we can gather as much intel as
>> possible, because I get the feeling that every discussion a lot of key
>> elements are named, but they all die in the end, together with the
>> discussion.
> Yeah, it's time that someone writes down all the stuff...
>
> It is time to implement something, even if it's very limited and
> supports only the basic scenarios.
True
> I think we should start with a simple script, get it into the tools
> directory so everyone interested can use it and add the fancy stuff later.
> Ofcourse we have to keep a few things in mind:
> - We want to add more features later without a lot of refactoring.
> - Maybe the tool should be split into frontend and backend to support
> different frontents (f.ex. cmdline/GUI, novice/expert version)
> - ... ?
At the moment I don't have anything to add. Just keep it simple.
> The choice of the language is also something we'll have to do.
> At the moment I would choose python, and C if we use the SVN API, just
> because I know those two pretty well.
I haven't ever worked with Python, but I don't mind learning.
I can at least program some C. I have played around with C and C++ and
I've had some C++ in school, but nothing too fancy. But I think I can
manage so these shouldn't be any problem.
But because I'm not that up2date with the languages and programming for
SVN I think you should start they project. At least if we have enough
information for a project ;)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Martin Furter <mf...@rola.ch>.
On Tue, 4 Jul 2006, Danny van Heumen wrote:
> Martin Furter wrote:
>> On Mon, 3 Jul 2006, Danny van Heumen wrote:
>>> *Some small scenarios worked out*
>>> So in order to prevent these missteps we should do the following:
>>>
>>> 1. Default to a repos layout that already has room for tags and
>>> branches.
>>>
>>> Possible formats:
>>> a. /trunk, /tags, /branches
>>> Use this if you're repository is used for only one project, or if
>>> you want a global trunk/tags/branches layout which will be used by
>>> all projects occupying to repository.
>>>
>>> b. /trunk/{project}, /tags/{project}, /branches/{project}
>>> The same as A, with the difference that it can be used for several
>>> projects.
>>>
>>> c. /{project}/trunk, /{project}/tags, /{project}/branches
>>> Use this if you want to store several projects in a single
>>> repository and you want to have a separate trunk/tags/branches
>>> layout for each of your projects.
>>>
>>> d. ... Some other layout I haven't encountered before ...
>>
>> We use a variant of b: /trunk/{group}/{project}, ...
>> Not sure if that qualifies as d. ;)
>
> It definitely does.
> Could you elaborate a bit on group?
> The way I understand it now is that group indicates something like a
> category for projects. I.e. Group: Internet, with projects that all
> relate to the internet in one way or another.
Yes, exactly, we grouped related projects, though, almost all of our
projects are related somehow, either directly or indirectly.
Here we have essentially two groups with projects, the projects in the
same group use (more or less) the same database tables.
We have these two groups twice, the old version and the new version. The
old ones are still used by some customers so we still have to fix bugs.
The new ones is where the development happens. Some of the projects in the
new groups are complete redesigns, some are forks of the old ones to add
new features.
Additionally we have groups containing libraries, communication software,
shared code, 3rd party software and one with misc stuff mostly for
internal use.
Ofcourse there are many ways to group projects.
In our old RCS-like VCS we had the groups server and client software (and
a few others) but most of the projects were in client-software so we used
the opportunity to rearrange the projects when we switched to subversion
two years ago.
It was pretty hard to find the 'right' layout but I guess we did a pretty
good job, there's only one project which I would put into a different
group today.
>> I agree, a script for creating new project directories would make life
>> easier.
>
> I don't know how this is in other countries. But here in Holland there's
> a very strong try-first-read-later approach when it comes to software
> and new (electronic) equipment.
> By supplying a wizard the try-first approach will push them in the right
> direction, until they learn why they took that direction.
> And when they understand the structure (and the idea behind it) they can
> also do any advanced actions/commands more easily and without a wizard.
Yes, same here.
But every game has its own rules... ;)
About 3 1/2 years ago I started playing with subversion, just to share
some sourcecode with a friend. About 6 month later the game had to be
expanded to new territory... so I converted 2 of our projects into SVN.
About a year later when we imported all of our projects I had 4 SVN
repositories, but we wanted all of our code in just one repository. So I
was forced to merge them somehow. And that is why svndumptool exists
today.
I guess the first question the wizard should ask is:
What do you want to do?
1. Play around with a toy repository.
2. Think about the layout for real repositories.
>>> 2. Use an alternative command for creating a branch or tag:
>>>
>>> The alternative command:
>>> a. Only allows the user to specify a tag/branch name.
>>>
>>> b. Chooses it's own location (This depends on the admin's choice
>>> in 1: layout A, B or C)
>>
>> I already did this, I made a web-interface for branching and tagging.
>> It needs some configuration and because I am lazy I just have a list of
>> project directories and two transformation rules for creating tag and
>> branch URLs.
>
> Well this seems like a good approach. Although we have to keep in mind
> that the wizard has to be easily accessible (all platforms, min.
> requirements) if we want users to work with it.
>
> Simplicity is *the* keyword at the moment. Clarity comes at a close
> second I guess.
Right.
But I guess if the administrative part of the tool is really good the rest
will become simple automatically.
>> But if the configuration would be made public somehow a script could
>> fetch it and do all these things.
>>
>> I could imagine a config file like this (which could be stored in the
>> repos as /repos.conf):
>
> Well you read my mind here. I haven't thought about what should be in
> the script, except for the type of layout that is chosen, but I also had
> this sort of thing in mind.
Though, that config file in the repository needs a few more thoughts.
If we put it into a directory (just containing that config file) we can
checout that dir into the config area of the wizard. If the file is in the
root directory of the repos we are forced to use the subversion API.
(not that I am against using it, it is just a dependency the tool will
have)
>>
>> [default]
>>
>> repos-url = http://svn.example.com/repos
>>
>> [project1]
>>
>> trunk = trunk/project1
>> tags = tags/project1
>> branches = branches/project1
>> start-rev = 123
>> end-rev = 0
>>
>> [dead-project]
>>
>> trunk = trunk/project1
>> tags = tags/project1
>> branches = branches/project1
>> start-rev = 12
>> end-rev = 165
>>
>> start-rev is the revision number where the project directory was
>> created, end-rev when it was deleted. I'm not sure yet if these two are
>> really needed, just an idea.
>>
>>
>>
>> But that reminds me that a remote config is not enough. A wrapper needs
>> a local config too which could list many remote config URLs.
>> Maybe a 'check for new projects' command would be nice too. It could
>> also ask for an alias name for the project.
>
> I think it's key to keep it simple. I figured that if we store a type of
> layout (i.e. /trunk, /trunk/{project}, /{project}/trunk, etc.) the alias
> would be '{project}'.
> If we store many variables in a file, the file has to be kept up-2-date
> all the time which could prove difficult if someone manually (without
> the wizard) changes something in the repository.
I was thinking about a commandline tool checkout and multiple
repositories. The user needs a way to specify which project of which
repository he wants to checkout, and there may be projects with the same
name in different repositories (or even in the same repos).
> The wizard shouldn't limit the user in it's possibilities, only guide.
> And I know that's going to be hard, but at least keep it in mind ;)
Yes, that's why I proposed to specify trunk tags and branches for each
project instead of a layout which must apply to all projects in teh same
repository.
But maybe that's not enough: What about support for things like
tags/releases, tags/release-candidates, ... ?
>>> PS: Plz post a lot of feedback on this idea (well... actually Erik
>>> Kline's idea) because I'd like to find out if it's feasible or not. And
>>> I don't mean just technically, but also what other admins think about
>>> the idea.
>>
>> Yes, let's collect a list of ideas. The next step would then be to find
>> out which commands the wrapper script should have.
>
> Maybe we should set something up, but I don't know what kind of thing is
> best to use for this kind of discussion and storing/working out ideas.
>
> Maybe a wiki or a forum or something?
I think a wiki would be nice for storing the ideas/specs/...
But for discussing things either a mailing list or a forum would be
better.
We could also use a SVN repository for storing the ideas and continue
discussing here.
I just don't know how long we can continue spamming this list until we get
kicked ;)
> I think it is very important that we can gather as much intel as
> possible, because I get the feeling that every discussion a lot of key
> elements are named, but they all die in the end, together with the
> discussion.
Yeah, it's time that someone writes down all the stuff...
>> I think it is feasible and we should implement it. It would be a nice
>> addition to tools/client-side and we could point everyone who tries to
>> restart this discussion to that tool :)
> I agree.
>
> I am willing to help and I have no school at the moment (summer
> vacation) so I've got at least some time available. (Got to work too.)
> But if I can help I'm happy to.
>
> I don't mind "managing" the discussion a bit if you'd like? Because I've
Yes, feel free to do that.
I am very busy this week and maybe part of the next week too, so i won't
be able to do much on this front.
> seen all other two-monthly discussions die and I think this can be
> really valuable.
Yeah, I've seen too many of these proposals and discussions too, and I
don't want to see this one stave too.
It is time to implement something, even if it's very limited and supports
only the basic scenarios.
I think we should start with a simple script, get it into the tools
directory so everyone interested can use it and add the fancy stuff
later.
Ofcourse we have to keep a few things in mind:
- We want to add more features later without a lot of refactoring.
- Maybe the tool should be split into frontend and backend to support
different frontents (f.ex. cmdline/GUI, novice/expert version)
- ... ?
The choice of the language is also something we'll have to do.
At the moment I would choose python, and C if we use the SVN API, just
because I know those two pretty well.
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Martin Furter wrote:
> On Mon, 3 Jul 2006, Danny van Heumen wrote:
>> *Some small scenarios worked out*
>> So in order to prevent these missteps we should do the following:
>>
>> 1. Default to a repos layout that already has room for tags and
>> branches.
>>
>> Possible formats:
>> a. /trunk, /tags, /branches
>> Use this if you're repository is used for only one project, or if
>> you want a global trunk/tags/branches layout which will be used by
>> all projects occupying to repository.
>>
>> b. /trunk/{project}, /tags/{project}, /branches/{project}
>> The same as A, with the difference that it can be used for several
>> projects.
>>
>> c. /{project}/trunk, /{project}/tags, /{project}/branches
>> Use this if you want to store several projects in a single
>> repository and you want to have a separate trunk/tags/branches
>> layout for each of your projects.
>>
>> d. ... Some other layout I haven't encountered before ...
>
> We use a variant of b: /trunk/{group}/{project}, ...
> Not sure if that qualifies as d. ;)
It definitely does.
Could you elaborate a bit on group?
The way I understand it now is that group indicates something like a
category for projects. I.e. Group: Internet, with projects that all
relate to the internet in one way or another.
>
> I agree, a script for creating new project directories would make life
> easier.
I don't know how this is in other countries. But here in Holland there's
a very strong try-first-read-later approach when it comes to software
and new (electronic) equipment.
By supplying a wizard the try-first approach will push them in the right
direction, until they learn why they took that direction.
And when they understand the structure (and the idea behind it) they can
also do any advanced actions/commands more easily and without a wizard.
>> 2. Use an alternative command for creating a branch or tag:
>>
>> The alternative command:
>> a. Only allows the user to specify a tag/branch name.
>>
>> b. Chooses it's own location (This depends on the admin's choice
>> in 1: layout A, B or C)
>
> I already did this, I made a web-interface for branching and tagging.
> It needs some configuration and because I am lazy I just have a list of
> project directories and two transformation rules for creating tag and
> branch URLs.
Well this seems like a good approach. Although we have to keep in mind
that the wizard has to be easily accessible (all platforms, min.
requirements) if we want users to work with it.
Simplicity is *the* keyword at the moment. Clarity comes at a close
second I guess.
> Additionally it knows where the projects store their version information
> and uses that to do some checks and propose branch and tag names (but
> that is a bit a too project specific feature).
Yep, this sounds like a very specific kind of approach. We want to keep
it as transparent as possible, because we don't want to confuse the
users any more than they are at the moment.
>> 3. Use an alternative command for checking out a working copy:
>>
>> The alternative command:
>> a. Asks for trunk, tag or branch. (Defaulting to trunk)
>>
>> Because it asks the user for the type (trunk/tag/branch), the user
>> probably won't complain about the '-r' argument not accepting a
>> tag/branch name. Because they've been offered the choice even
>> before they're asked for the revision.
>>
>> b. Asks for revision. (Defaulting to HEAD)
>>
>> Users can normally use the default, unless told otherwise by the
>> repos admin or a fellow programmer or so.
>>
>>
>> 4. Use an alternative command for switching between trunk/tag/branch.
>> (This works somewhat like 3)
>>
>>
>> 5. Use an alternative command for merging:
>>
>> The alternative command:
>> a. Asks for trunk/tag/branch to merge with current working copy
>> (No default)
>>
>> b. Asks for a range of revisions to merge.
>>
>> c. Asks for dry-run or merge.
>
> 3-5 are local things where a web-interface can't help.
I agree. This is more a script/application thing.
This is also why I think we should keep the whole 'wizard' a
script/application thing.
> But if the configuration would be made public somehow a script could
> fetch it and do all these things.
>
> I could imagine a config file like this (which could be stored in the
> repos as /repos.conf):
Well you read my mind here. I haven't thought about what should be in
the script, except for the type of layout that is chosen, but I also had
this sort of thing in mind.
>
> [default]
>
> repos-url = http://svn.example.com/repos
>
> [project1]
>
> trunk = trunk/project1
> tags = tags/project1
> branches = branches/project1
> start-rev = 123
> end-rev = 0
>
> [dead-project]
>
> trunk = trunk/project1
> tags = tags/project1
> branches = branches/project1
> start-rev = 12
> end-rev = 165
>
> start-rev is the revision number where the project directory was
> created, end-rev when it was deleted. I'm not sure yet if these two are
> really needed, just an idea.
>
>
>> 6. Etc.
> Diff would be nice too.
That's a good one.
>>> The only other way I can think to make it "generic" would be to have
>>> some sort of "variable" in the repo URL, like
>>> "http://example.com/repo/$TAGS_DIR/dir1/file1.cc" and let the server
>>> (or mod_rewrite?) do the fixup. Note: I'm not a fan of this idea, it
>>> just occurred to me to mention it.
>> I don't like this either.
>>
>>
>>> Alternatively I supposed there could be environment variables, like
>>> "SVN_TAGS_DIR" or "SVN_BRANCHES_DIR" that, if set and not empty, could
>>> be used to automatically construct the right repo urls somehow. But
>>> again, this is not obviously a great idea.
>> Nope, don't like this either. ;-)
>
> Those two have the problem that you can't work on multiple projects at
> the same time or always have to setup the env vars first.
>
> But that reminds me that a remote config is not enough. A wrapper needs
> a local config too which could list many remote config URLs.
> Maybe a 'check for new projects' command would be nice too. It could
> also ask for an alias name for the project.
I think it's key to keep it simple. I figured that if we store a type of
layout (i.e. /trunk, /trunk/{project}, /{project}/trunk, etc.) the alias
would be '{project}'.
If we store many variables in a file, the file has to be kept up-2-date
all the time which could prove difficult if someone manually (without
the wizard) changes something in the repository.
The wizard shouldn't limit the user in it's possibilities, only guide.
And I know that's going to be hard, but at least keep it in mind ;)
>> PS: Plz post a lot of feedback on this idea (well... actually Erik
>> Kline's idea) because I'd like to find out if it's feasible or not. And
>> I don't mean just technically, but also what other admins think about
>> the idea.
>
> Yes, let's collect a list of ideas. The next step would then be to find
> out which commands the wrapper script should have.
Maybe we should set something up, but I don't know what kind of thing is
best to use for this kind of discussion and storing/working out ideas.
Maybe a wiki or a forum or something?
I think it is very important that we can gather as much intel as
possible, because I get the feeling that every discussion a lot of key
elements are named, but they all die in the end, together with the
discussion.
> I think it is feasible and we should implement it. It would be a nice
> addition to tools/client-side and we could point everyone who tries to
> restart this discussion to that tool :)
I agree.
I am willing to help and I have no school at the moment (summer
vacation) so I've got at least some time available. (Got to work too.)
But if I can help I'm happy to.
I don't mind "managing" the discussion a bit if you'd like? Because I've
seen all other two-monthly discussions die and I think this can be
really valuable.
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Martin Furter <mf...@rola.ch>.
On Mon, 3 Jul 2006, Danny van Heumen wrote:
> Erik Kline wrote:
>> I am also a lurker. Just thought I'd chip in.
>>
>> Because the repository layout is specified by the repo admin(s)
>> (hurray) tagging and branching are probably best left in a wrapper
>> layer.
> I think you got a point there.
>
> So, in most cases it's not SVN that has the shortcoming of easy tagging,
> it's the Repo Admin that didn't set up the repository in a way that
> allows easy tagging. This is a possibility correct?
>
> And this is possible because SVN allows *us* to choose a location for
> the tags/branches.
>
>
> *Summary*
> I think it is important to have some sort of a wizard available to
> prevent Repos Admins from making mistakes in the initial repository layout.
> This wizard script/application makes some decisions on it's own thus
> preventing problems.
>
> Because the Repos Admin follows the wizard, the wizard can manipulate
>> :) the admin to create a repository in the SVN-way instead of the
> CVS-way. Because the CVS-habit is broken, the problem is (at least
> partially) solved.
>
>
> *Some small scenarios worked out*
> So in order to prevent these missteps we should do the following:
>
> 1. Default to a repos layout that already has room for tags and
> branches.
>
> Possible formats:
> a. /trunk, /tags, /branches
> Use this if you're repository is used for only one project, or if
> you want a global trunk/tags/branches layout which will be used by
> all projects occupying to repository.
>
> b. /trunk/{project}, /tags/{project}, /branches/{project}
> The same as A, with the difference that it can be used for several
> projects.
>
> c. /{project}/trunk, /{project}/tags, /{project}/branches
> Use this if you want to store several projects in a single
> repository and you want to have a separate trunk/tags/branches
> layout for each of your projects.
>
> d. ... Some other layout I haven't encountered before ...
We use a variant of b: /trunk/{group}/{project}, ...
Not sure if that qualifies as d. ;)
I agree, a script for creating new project directories would make life
easier.
> 2. Use an alternative command for creating a branch or tag:
>
> The alternative command:
> a. Only allows the user to specify a tag/branch name.
>
> b. Chooses it's own location (This depends on the admin's choice
> in 1: layout A, B or C)
I already did this, I made a web-interface for branching and tagging.
It needs some configuration and because I am lazy I just have a list of
project directories and two transformation rules for creating tag and
branch URLs.
Additionally it knows where the projects store their version information
and uses that to do some checks and propose branch and tag names (but that
is a bit a too project specific feature).
> 3. Use an alternative command for checking out a working copy:
>
> The alternative command:
> a. Asks for trunk, tag or branch. (Defaulting to trunk)
>
> Because it asks the user for the type (trunk/tag/branch), the user
> probably won't complain about the '-r' argument not accepting a
> tag/branch name. Because they've been offered the choice even
> before they're asked for the revision.
>
> b. Asks for revision. (Defaulting to HEAD)
>
> Users can normally use the default, unless told otherwise by the
> repos admin or a fellow programmer or so.
>
>
> 4. Use an alternative command for switching between trunk/tag/branch.
> (This works somewhat like 3)
>
>
> 5. Use an alternative command for merging:
>
> The alternative command:
> a. Asks for trunk/tag/branch to merge with current working copy
> (No default)
>
> b. Asks for a range of revisions to merge.
>
> c. Asks for dry-run or merge.
3-5 are local things where a web-interface can't help.
But if the configuration would be made public somehow a script could fetch
it and do all these things.
I could imagine a config file like this (which could be stored in the
repos as /repos.conf):
[default]
repos-url = http://svn.example.com/repos
[project1]
trunk = trunk/project1
tags = tags/project1
branches = branches/project1
start-rev = 123
end-rev = 0
[dead-project]
trunk = trunk/project1
tags = tags/project1
branches = branches/project1
start-rev = 12
end-rev = 165
start-rev is the revision number where the project directory was created,
end-rev when it was deleted. I'm not sure yet if these two are really
needed, just an idea.
> 6. Etc.
Diff would be nice too.
>> The only other way I can think to make it "generic" would be to have
>> some sort of "variable" in the repo URL, like
>> "http://example.com/repo/$TAGS_DIR/dir1/file1.cc" and let the server
>> (or mod_rewrite?) do the fixup. Note: I'm not a fan of this idea, it
>> just occurred to me to mention it.
> I don't like this either.
>
>
>> Alternatively I supposed there could be environment variables, like
>> "SVN_TAGS_DIR" or "SVN_BRANCHES_DIR" that, if set and not empty, could
>> be used to automatically construct the right repo urls somehow. But
>> again, this is not obviously a great idea.
> Nope, don't like this either. ;-)
Those two have the problem that you can't work on multiple projects at the
same time or always have to setup the env vars first.
But that reminds me that a remote config is not enough. A wrapper needs a
local config too which could list many remote config URLs.
Maybe a 'check for new projects' command would be nice too. It could also
ask for an alias name for the project.
> PS: Plz post a lot of feedback on this idea (well... actually Erik
> Kline's idea) because I'd like to find out if it's feasible or not. And
> I don't mean just technically, but also what other admins think about
> the idea.
Yes, let's collect a list of ideas. The next step would then be to find
out which commands the wrapper script should have.
I think it is feasible and we should implement it. It would be a nice
addition to tools/client-side and we could point everyone who tries to
restart this discussion to that tool :)
Martin
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Folker Schamel wrote:
> BTW, as mentioned, TSVN assumes the standard location of the tags directory
> in some cases (e.g. gives you an warning if you want to commit into it).
> I think tag and branch management works fine in TSVN.
Good point. I didn't know that TortoiseSVN reacts on these default
layout locations.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Folker Schamel <sc...@spinor.com>.
Danny van Heumen wrote:
> Folker Schamel wrote:
>> Quite the contrary:
>> When NOT using the SVN non-standard-project-layout feature,
>> which is not supported by other VC software anyway,
>> then you don't have a problem.
>
> Uhh... sorry, but I can't follow you in this reply...
> Could you rephrase that or elaborate a bit?
If you only use the standard project layout in subversion,
then for example <project-url>/../tags per definition always works.
So for all standard project layouts a tool know the location
of the tags directory.
BTW, as mentioned, TSVN assumes the standard location of the tags directory
in some cases (e.g. gives you an warning if you want to commit into it).
I think tag and branch management works fine in TSVN.
Cheers,
Folker
>
> Danny
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Folker Schamel wrote:
> Quite the contrary:
> When NOT using the SVN non-standard-project-layout feature,
> which is not supported by other VC software anyway,
> then you don't have a problem.
Uhh... sorry, but I can't follow you in this reply...
Could you rephrase that or elaborate a bit?
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Folker Schamel <sc...@spinor.com>.
>>>>> Make a program that lists all tags for a project (e.g. given the URL
>>>>> of
>>>>> the 'trunk').
>>>> svn list <trunk-url>/../tags/
>>> No, this will not work if you have layed out the project with /trunk,
>>> /tags and /branches in the root of the repository. The program cannot
>>> know
>>> your intentions without some meta-information.
>> Your program can assume (or try first) the standard layout.
>
> "assume"?? I am trying to find a solution in which Subversion "knows". Why
> do you not want to find such a solution?
>
> I was asked to give an example of a feature Subversion is lacking, and
> gave one. You seem to agree on that, using phrases like "assume" and "try
> first".
Quite the contrary:
When NOT using the SVN non-standard-project-layout feature,
which is not supported by other VC software anyway,
then you don't have a problem.
CHeers,
>
>> Your program can also store meta information in a svn property.
>
> This is what I am proposing, only that Subversion should manage the
> properties. You put the burden of the special property handling on every
> client, when it may be implemented once in Subversion.
>
> Håkon Hallingstad
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by ha...@ion.no.
>>>>> Btw: I don't want to crush all your arguments and tell you to quit
>>>>> complaining, it's just that I don't have that much experience with
>>>>> tagging used in company procedures etc. The scenarios I can come up
>>>>> with
>>>>> all seem to work in subversion. So I have to have some examples
>>>>> before
>>>>> I
>>>>> am able to see what subversion lacks. (And what subversion doesn't
>>>>> quite
>>>>> lack, but still is very hard to accomplish.)
>>>> Make a program that lists all tags for a project (e.g. given the URL
>>>> of
>>>> the 'trunk').
>>> svn list <trunk-url>/../tags/
>>
>> No, this will not work if you have layed out the project with /trunk,
>> /tags and /branches in the root of the repository. The program cannot
>> know
>> your intentions without some meta-information.
>
> Your program can assume (or try first) the standard layout.
"assume"?? I am trying to find a solution in which Subversion "knows". Why
do you not want to find such a solution?
I was asked to give an example of a feature Subversion is lacking, and
gave one. You seem to agree on that, using phrases like "assume" and "try
first".
> Your program can also store meta information in a svn property.
This is what I am proposing, only that Subversion should manage the
properties. You put the burden of the special property handling on every
client, when it may be implemented once in Subversion.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Folker Schamel <sc...@spinor.com>.
>>>> Btw: I don't want to crush all your arguments and tell you to quit
>>>> complaining, it's just that I don't have that much experience with
>>>> tagging used in company procedures etc. The scenarios I can come up
>>>> with
>>>> all seem to work in subversion. So I have to have some examples before
>>>> I
>>>> am able to see what subversion lacks. (And what subversion doesn't
>>>> quite
>>>> lack, but still is very hard to accomplish.)
>>> Make a program that lists all tags for a project (e.g. given the URL of
>>> the 'trunk').
>> svn list <trunk-url>/../tags/
>
> No, this will not work if you have layed out the project with /trunk,
> /tags and /branches in the root of the repository. The program cannot know
> your intentions without some meta-information.
Your program can assume (or try first) the standard layout.
For example, TSVN handles the tags/ and branches/
directories in a special way.
Subversion is more flexible allowing also other layouts,
but no program is forced to support all advanced features of SVN.
Your program can also store meta information in a svn property.
Or your program can locally cache the location of the tags directory.
I can understand that some people are not happy
with the command line interface of SVN tagging.
(Obviously other UIs can provide as nice UIs as they wish.)
But I don't see a problem with the tagging mechanism itself.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by ha...@ion.no.
>>> hakon@ion.no wrote:
>>>>> I think it is important to have some sort of a wizard available to
>>>>> prevent Repos Admins from making mistakes in the initial repository
>>>>> layout.
>>>> A wizard is nice, but it does not solve my issues. I want a better
>>>> tagging
>>>> interface, which has to be built-in to Subversion.
>>> Well, I understand that a wizard doesn't fix all our problems.
>>>
>>> When you say "tagging interface". Do you mean that you think Subversion
>>> has all the necessary support for tagging, but you just don't like the
>>> way to use it. (too many arguments, URL too long, etc.)
>>>
>>> Or do you think it lacks some kind of functionality? Maybe you can
>>> think
>>> of situations that aren't possible at all with the current tag support
>>> in subversion?
>>
>> The current Subversion scheme is difficult and too verbose for humans.
>> (Whether it is 'difficult' is controversial, though.)
>
> Well, I like the subversion tagging and branching mechanism very much.
Many people agree with you, and therefore we cannot change the current
mechanism, only improve it. This also means that my current suggestions
must be discarded in favor of a more 'backward compatible' solution.
>> For programs it is worse, because there is no built-in concept of a tag.
>> So Subclipse, for example, must ask the user to find the tags for it,
>> _then_ it may present the tags through the UI.
>>
>> But we are not very far from a better solution, the difficult part is
>> getting everyone to agree on one. :-)
>
> I think it is faaaaar away:
> I don't know a single alternative proposal which does not have
> serious problems, e.g. missing important features like version
> control of tags,
Well, this is taken care of in the current scheme, so it will work in the
improved scheme.
> or a more complex UI by having two different
> tagging mechanisms in parallel.
Yes, there is much opposition into bringing another tagging mechanism into
the scene. So we must make the new tagging mechanism work & feel like the
current - only improved.
>>> Btw: I don't want to crush all your arguments and tell you to quit
>>> complaining, it's just that I don't have that much experience with
>>> tagging used in company procedures etc. The scenarios I can come up
>>> with
>>> all seem to work in subversion. So I have to have some examples before
>>> I
>>> am able to see what subversion lacks. (And what subversion doesn't
>>> quite
>>> lack, but still is very hard to accomplish.)
>>
>> Make a program that lists all tags for a project (e.g. given the URL of
>> the 'trunk').
>
> svn list <trunk-url>/../tags/
No, this will not work if you have layed out the project with /trunk,
/tags and /branches in the root of the repository. The program cannot know
your intentions without some meta-information.
> Personally, I prefer a repository browser like in TSVN anyway,
> because there you can browse both trunk and tags itself,
> and browse into tags.
Other people may not agree with you, and Subversion needs to support all
of them.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Folker Schamel <sc...@spinor.com>.
>> hakon@ion.no wrote:
>>>> I think it is important to have some sort of a wizard available to
>>>> prevent Repos Admins from making mistakes in the initial repository
>>>> layout.
>>> A wizard is nice, but it does not solve my issues. I want a better
>>> tagging
>>> interface, which has to be built-in to Subversion.
>> Well, I understand that a wizard doesn't fix all our problems.
>>
>> When you say "tagging interface". Do you mean that you think Subversion
>> has all the necessary support for tagging, but you just don't like the
>> way to use it. (too many arguments, URL too long, etc.)
>>
>> Or do you think it lacks some kind of functionality? Maybe you can think
>> of situations that aren't possible at all with the current tag support
>> in subversion?
>
> The current Subversion scheme is difficult and too verbose for humans.
> (Whether it is 'difficult' is controversial, though.)
Well, I like the subversion tagging and branching mechanism very much.
For example, I think the CVS tagging and branching mechanism
is more difficult, because of this two-dimensional structure.
(Of course, if you are used to it...)
Not talking about important features missing,
for example version control of tags.
>
> For programs it is worse, because there is no built-in concept of a tag.
> So Subclipse, for example, must ask the user to find the tags for it,
> _then_ it may present the tags through the UI.
>
> But we are not very far from a better solution, the difficult part is
> getting everyone to agree on one. :-)
I think it is faaaaar away:
I don't know a single alternative proposal which does not have
serious problems, e.g. missing important features like version
control of tags, or a more complex UI by having two different
tagging mechanisms in parallel.
>
>> Btw: I don't want to crush all your arguments and tell you to quit
>> complaining, it's just that I don't have that much experience with
>> tagging used in company procedures etc. The scenarios I can come up with
>> all seem to work in subversion. So I have to have some examples before I
>> am able to see what subversion lacks. (And what subversion doesn't quite
>> lack, but still is very hard to accomplish.)
>
> Make a program that lists all tags for a project (e.g. given the URL of
> the 'trunk').
svn list <trunk-url>/../tags/
Personally, I prefer a repository browser like in TSVN anyway,
because there you can browse both trunk and tags itself,
and browse into tags.
>
> But my main motivation is not so solve something that cannot be done in
> the current scheme, but to make tags a built-in concept for Subversion.
> Then everything will fall into place.
Cheers,
Folker
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by ha...@ion.no.
> hakon@ion.no wrote:
>>> I think it is important to have some sort of a wizard available to
>>> prevent Repos Admins from making mistakes in the initial repository
>>> layout.
>>
>> A wizard is nice, but it does not solve my issues. I want a better
>> tagging
>> interface, which has to be built-in to Subversion.
> Well, I understand that a wizard doesn't fix all our problems.
>
> When you say "tagging interface". Do you mean that you think Subversion
> has all the necessary support for tagging, but you just don't like the
> way to use it. (too many arguments, URL too long, etc.)
>
> Or do you think it lacks some kind of functionality? Maybe you can think
> of situations that aren't possible at all with the current tag support
> in subversion?
The current Subversion scheme is difficult and too verbose for humans.
(Whether it is 'difficult' is controversial, though.)
For programs it is worse, because there is no built-in concept of a tag.
So Subclipse, for example, must ask the user to find the tags for it,
_then_ it may present the tags through the UI.
But we are not very far from a better solution, the difficult part is
getting everyone to agree on one. :-)
> Btw: I don't want to crush all your arguments and tell you to quit
> complaining, it's just that I don't have that much experience with
> tagging used in company procedures etc. The scenarios I can come up with
> all seem to work in subversion. So I have to have some examples before I
> am able to see what subversion lacks. (And what subversion doesn't quite
> lack, but still is very hard to accomplish.)
Make a program that lists all tags for a project (e.g. given the URL of
the 'trunk').
But my main motivation is not so solve something that cannot be done in
the current scheme, but to make tags a built-in concept for Subversion.
Then everything will fall into place.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
hakon@ion.no wrote:
>> I think it is important to have some sort of a wizard available to
>> prevent Repos Admins from making mistakes in the initial repository
>> layout.
>
> A wizard is nice, but it does not solve my issues. I want a better tagging
> interface, which has to be built-in to Subversion.
Well, I understand that a wizard doesn't fix all our problems.
When you say "tagging interface". Do you mean that you think Subversion
has all the necessary support for tagging, but you just don't like the
way to use it. (too many arguments, URL too long, etc.)
Or do you think it lacks some kind of functionality? Maybe you can think
of situations that aren't possible at all with the current tag support
in subversion?
Btw: I don't want to crush all your arguments and tell you to quit
complaining, it's just that I don't have that much experience with
tagging used in company procedures etc. The scenarios I can come up with
all seem to work in subversion. So I have to have some examples before I
am able to see what subversion lacks. (And what subversion doesn't quite
lack, but still is very hard to accomplish.)
Danny
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by ha...@ion.no.
> I think it is important to have some sort of a wizard available to
> prevent Repos Admins from making mistakes in the initial repository
> layout.
A wizard is nice, but it does not solve my issues. I want a better tagging
interface, which has to be built-in to Subversion.
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Barry Scott <ba...@barrys-emacs.org>.
On Jul 3, 2006, at 19:12, Danny van Heumen wrote:
> *Some small scenarios worked out*
> So in order to prevent these missteps we should do the following:
>
> 1. Default to a repos layout that already has room for tags and
> branches.
>
> Possible formats:
> a. /trunk, /tags, /branches
> Use this if you're repository is used for only one project, or if
> you want a global trunk/tags/branches layout which will be
> used by
> all projects occupying to repository.
>
> b. /trunk/{project}, /tags/{project}, /branches/{project}
> The same as A, with the difference that it can be used for
> several
> projects.
>
> c. /{project}/trunk, /{project}/tags, /{project}/branches
> Use this if you want to store several projects in a single
> repository and you want to have a separate trunk/tags/branches
> layout for each of your projects.
>
> d. ... Some other layout I haven't encountered before ...
I use /trunk/{group}/{project}, /tags/{group}/{project}, /branches/
{group}/{project}
on pysvn and at work.
>
> 6. Etc.
>
Example log out:
641 | barryscott | 2006-04-23 10:21:34 | Tag 1.4.2
634 | barryscott | 2006-04-16 16:45:39 | | Fix bug in
set_default_us
627 | barryscott | 2006-04-09 16:52:51 | | Add new Client
() set and
622 | barryscott | 2006-03-26 10:53:18 | Tag 1.4.1
607 | barryscott | 2006-03-11 11:50:56 | | Add /usr/local/
lib64 to
When I look at the svn log on the trunk I want to know which tags
correspond to
which revisions. Its then easy to see if a change made it into a
particular release.
In the example I can see that the bug fixed in 634 is in 1.4.2 but
not 1.4.1
I have an implementation in pysvn WorkBench that does this, but it
relies
on the user configuring the tags paths and that tags are created
before more
commits to the trunk. From the GUI its easy to then diff any version
against
a tag.
[I realized when reading this thread that I should have used
svn_client_log to get the history of the tags dir and use the path
info to figure out
the copy_from_rev, I was using svn_client_ls to get the list of tags
and use the
date, but that is error prone.]
Barry
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Erik Kline wrote:
> I am also a lurker. Just thought I'd chip in.
>
> Because the repository layout is specified by the repo admin(s)
> (hurray) tagging and branching are probably best left in a wrapper
> layer.
I think you got a point there.
So, in most cases it's not SVN that has the shortcoming of easy tagging,
it's the Repo Admin that didn't set up the repository in a way that
allows easy tagging. This is a possibility correct?
And this is possible because SVN allows *us* to choose a location for
the tags/branches.
*Summary*
I think it is important to have some sort of a wizard available to
prevent Repos Admins from making mistakes in the initial repository layout.
This wizard script/application makes some decisions on it's own thus
preventing problems.
Because the Repos Admin follows the wizard, the wizard can manipulate
>:) the admin to create a repository in the SVN-way instead of the
CVS-way. Because the CVS-habit is broken, the problem is (at least
partially) solved.
*Some small scenarios worked out*
So in order to prevent these missteps we should do the following:
1. Default to a repos layout that already has room for tags and
branches.
Possible formats:
a. /trunk, /tags, /branches
Use this if you're repository is used for only one project, or if
you want a global trunk/tags/branches layout which will be used by
all projects occupying to repository.
b. /trunk/{project}, /tags/{project}, /branches/{project}
The same as A, with the difference that it can be used for several
projects.
c. /{project}/trunk, /{project}/tags, /{project}/branches
Use this if you want to store several projects in a single
repository and you want to have a separate trunk/tags/branches
layout for each of your projects.
d. ... Some other layout I haven't encountered before ...
2. Use an alternative command for creating a branch or tag:
The alternative command:
a. Only allows the user to specify a tag/branch name.
b. Chooses it's own location (This depends on the admin's choice
in 1: layout A, B or C)
3. Use an alternative command for checking out a working copy:
The alternative command:
a. Asks for trunk, tag or branch. (Defaulting to trunk)
Because it asks the user for the type (trunk/tag/branch), the user
probably won't complain about the '-r' argument not accepting a
tag/branch name. Because they've been offered the choice even
before they're asked for the revision.
b. Asks for revision. (Defaulting to HEAD)
Users can normally use the default, unless told otherwise by the
repos admin or a fellow programmer or so.
4. Use an alternative command for switching between trunk/tag/branch.
(This works somewhat like 3)
5. Use an alternative command for merging:
The alternative command:
a. Asks for trunk/tag/branch to merge with current working copy
(No default)
b. Asks for a range of revisions to merge.
c. Asks for dry-run or merge.
6. Etc.
> Specifically: "svn_wrapper tag ..." and "svn_wrapper branch
> ..." could parse the repo URLs and reformat them according to your
> repo layout. I'm sure no one wants to force /repo/tags/ and
> /repo/branches/ on the world, especially when some folks (myself
> included) use /repo/project{1,2,3,...}/{trunk,tags,branches}/.
See 1.
> The only other way I can think to make it "generic" would be to have
> some sort of "variable" in the repo URL, like
> "http://example.com/repo/$TAGS_DIR/dir1/file1.cc" and let the server
> (or mod_rewrite?) do the fixup. Note: I'm not a fan of this idea, it
> just occurred to me to mention it.
I don't like this either.
> Alternatively I supposed there could be environment variables, like
> "SVN_TAGS_DIR" or "SVN_BRANCHES_DIR" that, if set and not empty, could
> be used to automatically construct the right repo urls somehow. But
> again, this is not obviously a great idea.
Nope, don't like this either. ;-)
I think it's pretty clear that I think that SVN is just like it should
be. It's just that people have to be taught what the SVN way is.
Danny
PS: Plz post a lot of feedback on this idea (well... actually Erik
Kline's idea) because I'd like to find out if it's feasible or not. And
I don't mean just technically, but also what other admins think about
the idea.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Erik Kline <ek...@google.com>.
On 7/3/06, Miha Vitorovic <mv...@nil.si> wrote:
> Danny van Heumen <da...@hccnet.nl> wrote on 03.07.2006 00:41:22:
>
> > John Peacock wrote:
> > > Mark Phippard wrote:
> > >> 5) As others have pointed out, a single property value cannot easily
>
> > >> express a complex mixed-revision tag.
> > >
> > > As long as the property value or "tag" is an alias for the actual copy
> to some
> > > tag folder, then this isn't a problem at all. The existing Subversion
> cheap
> > > copy becomes the backend implementation and the tag becomes the user
> friendly
> > > front end...
> > >
> > > John
> > >
> >
> > (This reply isn't aimed at anybody in specific,
> > it's just my view of the problem.)
> >
> > Come on guys... how 'user friendly' can you get?
> > The only thing you need to do now is look for a specific name in a
> > folder called 'tags' (or in case of a branche in the folder 'branches'
> > for that matter).
> > And instead of saying 'check out tag "mytag"' you say 'check out url
> > "http://domain.com/repos/tags/mytag"', or even '/tags/mytag' should be
> > enough. And in case you can't remember that, send yourself an email.
>
> Hi all,
>
> I'm just a user / dev-lurker, and I would like to offer my input. I've
> never used any other VCS, so I find the concept of "versioned file system"
> very easy to understand and use. So I don't see a problem with tags as
> folders, but I would quite welcome some tagging/branching that would
> remove the need for long URLs (and if you're doing a server side tag, than
> you usually need two of them - almost identical).
> As a SVN admin (small developer base, not much administration) I would
> find the ability to force some things on the server side quite valuable -
> which would also come in play with some tagging suggestions that are
> currently on the list.
> This current "better tagging" suggestion (if I'm not mistaken) yet again
> asks for symbolic revision numbers, so I guess many Subversion users want
> this quite badly. Why not finally give it them?
I am also a lurker. Just thought I'd chip in.
Because the repository layout is specified by the repo admin(s)
(hurray) tagging and branching are probably best left in a wrapper
layer. Specifically: "svn_wrapper tag ..." and "svn_wrapper branch
..." could parse the repo URLs and reformat them according to your
repo layout. I'm sure no one wants to force /repo/tags/ and
/repo/branches/ on the world, especially when some folks (myself
included) use /repo/project{1,2,3,...}/{trunk,tags,branches}/.
The only other way I can think to make it "generic" would be to have
some sort of "variable" in the repo URL, like
"http://example.com/repo/$TAGS_DIR/dir1/file1.cc" and let the server
(or mod_rewrite?) do the fixup. Note: I'm not a fan of this idea, it
just occurred to me to mention it.
Alternatively I supposed there could be environment variables, like
"SVN_TAGS_DIR" or "SVN_BRANCHES_DIR" that, if set and not empty, could
be used to automatically construct the right repo urls somehow. But
again, this is not obviously a great idea.
-ek
> I don't think that SVN tagging should become like CVS tagging (I like SVN
> tagging), but I think it is becoming more and more important that SVN
> developers do SOMETHING to scratch the biggest user itches, and add some
> functionality that would enable people to tag/branch in some other way
> except the current one. I guess some people just can't/don't want to wrap
> their heads around a concept that is different from what they know (and
> such people can be seen on both sides). From what I know about Subversion,
> I think it is flexible enough to be able to offer that (almost anything,
> actually).
>
> Regards,
> ---
> Miha Vitorovic
> Inženir v tehničnem področju
> Customer Support Engineer
>
> NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
> Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
>
>
Re: Tags
Posted by Lars Gullik Bjønnes <la...@gullik.net>.
Danny van Heumen <da...@hccnet.nl> writes:
| > As to devel... one (seemingly) small thing that would make life
| > easier for me would be if it were possible to put a needs-lock on a
| > directory.
| >
|
| Good point ;)
| I guess you mean automagically putting a needs-lock on all files inside
| a directory (recursively?). Or did you mean locking the directory so
| that no one can alter it's svn properties? (Guess not :))
Yes, automagically needs-lock on all files inside the dir would be
what I am after.
--
Lgb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
Lars Gullik Bjønnes wrote:
> Danny van Heumen <da...@hccnet.nl> writes:
>
> | PS: How can a better Version Control System be created if it keeps
> | getting compared with other VCS. And even to CVS which it is trying to
> | replace... If we build everything exactly the same, why build it? Just
> | use CVS :-)
>
> How can a better Version Control System be created in a vacuum? Of
> course you have to compare to other VCS, both as a source for
> inspiration, features, how to _not_ do things, but also _how_ to do
> things.
Very, very true!
As a source of inspiration for features it is always a good idea. I
always like to keep an open mind (and I hope everyone does).
As for 'how to do' or 'how not to do' things, that really depends on the
situation. As for SVN, at least this is how I understand it, the cheap
copy is a very (simple) powerful feature. Because of this feature I
think it has outgrown the CVS-like approach for tags.
Btw: I think we really really need to make a list of all pros and cons
to SVNs way of tagging/branching because this discussion is starting
every two (or so) months. I guess it will never stop until we work out
the scenarios/issues/(im)possibilities/etc.
I alone could not work out all scenarios because I don't have enough
experience with VCS. (And I haven't experienced enough companies using
VCS yet ;) )
I guess working out scenarios is also the best way to come to an
alternative approach (interface or implementation) for the developers
without comparing directly to another VCS.
*** If someone is really interested in working out some scenarios with
tags/branches, plz contact me off-the-list. ***
>
> As to devel... one (seemingly) small thing that would make life
> easier for me would be if it were possible to put a needs-lock on a
> directory.
>
Good point ;)
I guess you mean automagically putting a needs-lock on all files inside
a directory (recursively?). Or did you mean locking the directory so
that no one can alter it's svn properties? (Guess not :))
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Lars Gullik Bjønnes <la...@gullik.net>.
Danny van Heumen <da...@hccnet.nl> writes:
| PS: How can a better Version Control System be created if it keeps
| getting compared with other VCS. And even to CVS which it is trying to
| replace... If we build everything exactly the same, why build it? Just
| use CVS :-)
How can a better Version Control System be created in a vacuum? Of
course you have to compare to other VCS, both as a source for
inspiration, features, how to _not_ do things, but also _how_ to do
things.
As to devel... one (seemingly) small thing that would make life
easier for me would be if it were possible to put a needs-lock on a
directory.
--
Lgb
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Miha Vitorovic <mv...@nil.si>.
Danny van Heumen <da...@hccnet.nl> wrote on 03.07.2006 00:41:22:
> John Peacock wrote:
> > Mark Phippard wrote:
> >> 5) As others have pointed out, a single property value cannot easily
> >> express a complex mixed-revision tag.
> >
> > As long as the property value or "tag" is an alias for the actual copy
to some
> > tag folder, then this isn't a problem at all. The existing Subversion
cheap
> > copy becomes the backend implementation and the tag becomes the user
friendly
> > front end...
> >
> > John
> >
>
> (This reply isn't aimed at anybody in specific,
> it's just my view of the problem.)
>
> Come on guys... how 'user friendly' can you get?
> The only thing you need to do now is look for a specific name in a
> folder called 'tags' (or in case of a branche in the folder 'branches'
> for that matter).
> And instead of saying 'check out tag "mytag"' you say 'check out url
> "http://domain.com/repos/tags/mytag"', or even '/tags/mytag' should be
> enough. And in case you can't remember that, send yourself an email.
Hi all,
I'm just a user / dev-lurker, and I would like to offer my input. I've
never used any other VCS, so I find the concept of "versioned file system"
very easy to understand and use. So I don't see a problem with tags as
folders, but I would quite welcome some tagging/branching that would
remove the need for long URLs (and if you're doing a server side tag, than
you usually need two of them - almost identical).
As a SVN admin (small developer base, not much administration) I would
find the ability to force some things on the server side quite valuable -
which would also come in play with some tagging suggestions that are
currently on the list.
This current "better tagging" suggestion (if I'm not mistaken) yet again
asks for symbolic revision numbers, so I guess many Subversion users want
this quite badly. Why not finally give it them?
I don't think that SVN tagging should become like CVS tagging (I like SVN
tagging), but I think it is becoming more and more important that SVN
developers do SOMETHING to scratch the biggest user itches, and add some
functionality that would enable people to tag/branch in some other way
except the current one. I guess some people just can't/don't want to wrap
their heads around a concept that is different from what they know (and
such people can be seen on both sides). From what I know about Subversion,
I think it is flexible enough to be able to offer that (almost anything,
actually).
Regards,
---
Miha Vitorovic
Inženir v tehničnem področju
Customer Support Engineer
NIL Data Communications, Tivolska cesta 48, 1000 Ljubljana, Slovenia
Phone +386 1 4746 500 Fax +386 1 4746 501 http://www.NIL.si
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Danny van Heumen <da...@hccnet.nl>.
John Peacock wrote:
> Mark Phippard wrote:
>> 5) As others have pointed out, a single property value cannot easily
>> express a complex mixed-revision tag.
>
> As long as the property value or "tag" is an alias for the actual copy to some
> tag folder, then this isn't a problem at all. The existing Subversion cheap
> copy becomes the backend implementation and the tag becomes the user friendly
> front end...
>
> John
>
(This reply isn't aimed at anybody in specific,
it's just my view of the problem.)
Come on guys... how 'user friendly' can you get?
The only thing you need to do now is look for a specific name in a
folder called 'tags' (or in case of a branche in the folder 'branches'
for that matter).
And instead of saying 'check out tag "mytag"' you say 'check out url
"http://domain.com/repos/tags/mytag"', or even '/tags/mytag' should be
enough. And in case you can't remember that, send yourself an email.
The suggested solutions (I've read in the short time I've been reading
this list) all 'feel' like workarounds to me, and I don't really like it
(not that I have anything to say about it :P).
Every suggestion against the SVN-tags and SVN-branches was made from a
point of view where people compare it directly to other Version Control
Systems.
I'd really really like the SVN approach because of one thing: they kept
the concept simple. Why change a simple *and* working concept to
something more complicated and slower (i.e. because of the tag searching).
Simple things tend to work the best and often prove to be the most
flexible and stable.
(I.e. check the guy that sold 1,000,000 pixels on his webpage for $1
each. Simple and very effective :-) )
If we would build a Trojan Horse (the Greek type, not the viral type)
would we build it out of wood just because 'we know' wood? No ofcourse
not, we would build it out of some strong metal or even gold if it could
persuade our enemy... Instead of walking in with some cheap-ass wooden
knock-off.
Danny
PS: How can a better Version Control System be created if it keeps
getting compared with other VCS. And even to CVS which it is trying to
replace... If we build everything exactly the same, why build it? Just
use CVS :-)
PPS: Sorry guys, I just had to send this in...
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by John Peacock <jp...@rowman.com>.
Mark Phippard wrote:
> 5) As others have pointed out, a single property value cannot easily
> express a complex mixed-revision tag.
As long as the property value or "tag" is an alias for the actual copy to some
tag folder, then this isn't a problem at all. The existing Subversion cheap
copy becomes the backend implementation and the tag becomes the user friendly
front end...
John
--
John Peacock
Director of Information Research and Technology
Rowman & Littlefield Publishing Group
4501 Forbes Blvd
Suite H
Lanham, MD 20706
301-459-3366 x.5010
fax 301-429-5747
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by Mark Phippard <ma...@softlanding.com>.
hakon@ion.no wrote on 07/01/2006 09:40:13 AM:
> Would you care to mention the difficulties with properties? All I can
> think of is:
> 1. It is not possible to commit changes to single property on a
> file/directory.
> 2. It is not simple to search properties based on their values. Or sort
> the properties based on their values.
These are the main issues with using properties as I see them:
1) The property needs to be available in the WC to be used. If the tag
property is just on a specific folder, and you checked out some
sub-folder, then now you don't have the property available to be used.
This is why the feature works in Subclipse, because there are very
specific folders that an Eclipse user will check out. Setting the
property on every folder is unmanageable. The solution we have talked
about is something called "inherited properties", but there are some messy
issues to deal with to do that.
2) You cannot set a property directly on a URL. This is technically
feasible, it just has not been allowed or exposed. In this case, since
you'd only want to append to the existing value, maybe it would be a
capability that could be added?
3) Since properties are versioned, they require a commit. This might be
the sort of thing that could be combined with #2 so that if we had a
special svn tag command, it could under-the covers, to the copy and the
update of the tag property in a single atomic operation.
4) Once you have properties they are not easily searchable. For this
particular feature, I am not sure how significant a problem that is.
5) As others have pointed out, a single property value cannot easily
express a complex mixed-revision tag.
Thanks
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Tags
Posted by ha...@ion.no.
>> *) The Subversion concept of a tag is that it is a directory (in HEAD).
>> While other VCS uses a concept of tags which is a revision number (or a
>> path and a revision number).
>>
>> The proposed solution of putting tags as special properties solves all
> of
>> them.
>
> It doesn't, and without major API changes to properties it couldn't work.
> Your proposed solution was not very well thought out. Look at the Apache
> repository at http://svn.apache.org/repos/asf. There are 39 different
> projects. How could you store all of the tags in revision 0 of the
> repository root and have the feature work and have meaning?
You are confusing the original suggestion of using revision properties on
revision 0, with the one we now are discussing (suggested in
http://subversion.tigris.org/servlets/ReadMsg?list=dev&msgNo=117272).
All Apache projects will have their own tag namespaces, defined as
non-revision properties on (typically) the project/branch directory. (The
proposed implementation stores tags pr branch, but now I think tags should
be stored pr project.)
> Doing
> something like Subclipse where the properties are stored as versioned
> properties within the repository would work conceptually but there are a
> lot of real API hurdles to overcome before that could be done. It might
> be worthwhile to head further down this path and work up a real design,
> but I have a feeling that to implement this "tag" feature you would have
> to dive into large thorny areas like changing how properties work.
Using non-revision properties makes them versioned.
Would you care to mention the difficulties with properties? All I can
think of is:
1. It is not possible to commit changes to single property on a
file/directory.
2. It is not simple to search properties based on their values. Or sort
the properties based on their values.
> 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.
That's the goal. I just have to figure out which designs you like. :-)
Håkon Hallingstad
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org