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
Received on Mon Jul 3 20:11:57 2006