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
Received on Tue Jul 4 02:55:55 2006