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
Received on Mon Jul 3 23:42:38 2006