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
Received on Tue Jul 4 19:08:09 2006