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
Received on Tue Jul 4 00:21:26 2006