Re: [glob2-devel] Hello, I'm back, and lots of comments....

[Kai Antweiler]

>> Having two separated branches is easy in cvs.  The tricky part is
>> merging some changes between them.  And here even cvs is better than
>> having two totally separated systems.
>
>
> Again, the point is not to abandon CVS, but use SVN for the 0.9.0 branch.
> That way CVS remains working, while SVN could be broken for a week or month.

As I said: two totally separated systems  (that is cvs and svn)


>> Could work.  But even if it is better, the users have to accept it.
>> Our bugtracker is rejected by lots of people even where it has
>> advantages.  We can try to offer trac for new wishes, bugs and tasks
>> and see how well it gets accepted.
>
>
> The system is a lot more user friendly. It should allow a lot more options
> during development (like having the bugs link to the problem file for
> instant review :P).

But the important part is keeping track of the history and using it
well for merging.  And here svn does not perform well.
When once in a while Bradley will upload a whole bunch of code a lot
of the changes from other programmers will get lost (like it is now,
and will be with svn), nobody will be glad about having the bug tracker
on the same system as the wiki.

By the way local repositories allow for more options.
I have used them for finding bugs in part of the code that I don't know,
and statistics that about our code changing speed for individual developers.


>> I don't care if our central repository is in place A, the bug tracker in
>> place B, the documentation in place C and the mailing list is in place D.
>> This is at worst a very minor inconvenience.
>
>
> I disagree. Everything should be in one place. Its easier for everyone.

In a perfect world we come up with a perfect system.
But on earth we have recognize that that is a very very minor issue,
while getting your work lost on a project that has not much coders
or having to wait with your developement until someone else has finished
his is a big issue.

Also very big feature: with local repositories you don't need to know
your commands as well.  If something doesn't work right - it's only local,
until you push.  Especially newbies like that.  Remember the first time
you commited to a cvsserver?  Double and triple checked that everything
get's right.  Rereading the commands.  And then being excited, not knowing
if everything went right?
With local repositories you'll see every thing works well, and just push
it.

> Especially as I said above, the bug tracker etc should (in theory)
> automatically link to files and such when reports are posted.

Look in our bug tracker.  The number of bugs of which we know to
which file they belong is very limited.


> I know that Bradley won't like this.
>
>
> Why?

Because he wrote that he wants to write new stuff now and not wait on
the bug fixes.  With a good scms that merges well - no problem.

> I'm sure a reasonable programmer can see that at one point, you have to
> make a drastic change for the better. Finishing all features, fixing all
> bugs, releleasing Alpha 23,

We will never finish all bugs or features.
Glob2 is an always will be work in progress.

> then restricting devel on CVS to mostly bug fixes is the best
> thing.

Well Bradley and Steph are reasonable.  And both want to do their
new features now.  We are no software company that can tell it's
developers what to do.  If someone things it is the right time
to code something, we better let them.  With proper branching
there is no problem.


> No thanks.  I constantly use it when fixing bugs.  And when you loose
>> history you can't merge efficiently anymore.  All but one branch in
>> Devjavu
>> will defacto be lost.
>
>
> Thats the kind oif thinking that keeps Globulation behind.

No, that is lack of workforce.  But with Bradley working so hard
we aren't that bad, considering the age of the project.
But nevertheless workforce is the most important problem.


> You have to eventually make a choice, and if loosing some history is
> it, so be it. But again, the code wouldn't be imported until bugs
> have been fixed. If there is no need to revert since all new code in
> 0.9.0 will be broken once develoment starts, isn't having histroy
> from import more important (reverting all the new bug if something
> goes wrong?).

We won't fix all bugs.  And when I fix a bug I sometimes try to
find the last release that worked well and look what changes introduced
the bug.  If it is pretty old, I need history from long ago.


> This argument is in my opinion very inferior.
>> With a system like git we wouldn't even a discussion with Bradley whether
>> we should have quick bugfix release next.  Using different branches would
>> be natural.  And merging would work well.
>
>
> And you can't do that with SVN because........? 

Branches and merging often causes problems, because SVN wasn't intended
to be good scms, it was intended as a big cvs bugfix.  The developers
are just now hacking support for history for merge into svn, while the
new system where build around this feature.


> I've heard is really good, and  tagging (releases) is as simple as running a
> line of code (or was it two? :S).

And with a bit of luck it was a success.


> The point is, SVN is just as good as Git,

No, it is not.  Don't tell that Linus or you get a linux ban.


> but both are better than CVS.

True, svn is better than cvs.  And git is a lot better.


> So it doesn't matter where it moves to, as
> long as it provides something better, and allows development work to keep in
> a central place.

So why move to the worse sollution?
Don't say it.  Because there is everything on the same server.


>> I hear a lot of people talking about how good svn is.  When I ask about
>> it's advantages to git, darcs, monotone, mercurial or bazaar I always
>> hear that they haven't tried them.
>> So instead of spending your time to port everything right now, better
>> have a look at those systems.
>
>
> Why look at those other systems though? We arn't doing a debate of Source
> management tools, "this offers this" :P.

Arrgh!
That is the important point.  The scms we choose has a big influence
on how we work and what we work on.  Just saying I know one so
we must use it, is far from being the best choice.


> We are talking about moving to anything other than CVS.

We are talking (in fact we already have talked over this in the mailing
list) about which system to change on.  And the best for us, in my opinion,
will be git on savannah.


> If you can find a great, online 24/7, free source management tool,
> with the ability to have multi page documentation and bug tracker,
> then let me know.

Savannah.  We just don't use its documentation sites.


> The other reason I chose svn too is because its
> so easy to migrace to. cvs update becomes svn update, and likewise for
> commit, and other commands.

Thats the kind of thinking that keeps svn behind.  You have to
eventually make a choice, and if loosing some compatibility is it, so
be it.

-- 
Kai Antweiler