Re: ATTN: Initial test to move to Subversion started

From: Mark Gilbert <mg_abimail_at_yahoo.com>
Date: Fri Apr 08 2005 - 07:35:20 CEST

On Thu, 2005-04-07 at 23:48 -0400, sum1_lists@yahoo.com wrote:
> J.M. Maurer wrote:

I'm inclined to agree with sum1. If it ain't broke, don't fix it.

> >
> > There are several reasons why we want to make the change, such as:
> >
> > - Commits are atomic

Because if sum1 happens to update halfway through a repo-wide commit by
martin, which surely is an everyday occurence in a massively
collaborative, thousand-developer, sponsored project like abiword, and a
bug shows up, there's no way sum1 is going to think to cvsup and verify
that it hasnt already been fixed before reporting. Surely... (-:

> > - Directories, renames, and file meta-data are versioned

Yeah...because we say all the time how we need to version directory
metadata...amazing we lived so long without it?

> > - Move efficient than cvs, bandthwidth wise

See sum1's point below. Considering my download is now 1/10th the speed
it used to be (since we switched from my locally-collocated sf mirror to
downloading from the netherlands), I don't buy the bandwidth thing.

> > - Per commit version numbers, as opposed to per file (YAY!)

Ho joy. ... .... uhm, now, I've had this conversation with plam, and
it basically came down to if you're used to cvs, you're used to using
the cvs-way to do repo-wide queries (IOW, so what). It may not be
primordially superior, but, well, having used it with abiword
successfully since the last millennium, I think I'm used to it.

> > - cvs is 'dead' (although a new project has setup to continue, cvsnt)

yeah, nice quotes there (-: I'm not sure I should even try to address
this.

>
> This reads more like a list of why SVN is better than CVS in general
> rather than why SVN is better than CVS for AbiWord. The bandwidth reason
> seems weak too, considering the recent switch away from SourceForge.
>

I agree.

In any case, I've seen A) Reasons not to use SVN B) Reasons to use SVN
C) Rebuttal of reasons to use SVN D) Restatement of reasons to use SVN,
and basically, the death of a conversation, based on the assumption that
lack of support would lead to the proposition's being tabled. What I
seem to have overlooked was when the conversation was brought back to
life... but looking through my AbiWordDev mailbox for the last few
months, I don't see it.

I don't want to oppose SVN though. I want to by a die-hard opponent of
all forms of bandwagoning and decision-making in the absence of the
utmost extreme of dispassionate intellectual rigor.

> >
> > For a start, I switched over some cvs modules to subversion. No-one

Which begs simple but afaict unanswered questions. Again, I realize I
might have missed the extensive ml posts about this recently, so if you
could kindly point me for example to the message explaining why we
should deny people anonymous cvs, er, subversive access to facilitate
submission of patches to the website (diffing the generated content
served up by the web server is hardly less than absurd). Surely you
don't think we're any more secure for it?

> > except the system admins are affected by this change. We will test out

That's a hefty exception in my opinion, for a variety of reasons. 1)
Not all the admins are involved in this change 2) ***The admins are
developers too! We don't have a lot of developers! As sum1 points out
in fewer words, why should you waste, er, reallocate so much as ten
minutes of time arguably better spent coding abiword for the greater
good of humanity?*** 3) Again, if it aint broke, don't fix it. Why?
What don't change don't break. Personally I'm entirely in favour of
taking Dom's mom's advice on this one.
But again, not because I oppose SVN, but because I oppose a perceived
lack of necessity, justification, intellectual rigor, and surely
important in this setting, unanimity.

> > the current setup, and if it satisfies our needs, we will switch over
> > all our cvs repositories (the complete cvs history will be migrated too,
> > so we don't loose valuable information). Of course, such a change would
> > be announced weeks in advance.

And all related services? Like bonsai, which is still actively used?
It's doable, but this is something that needs to be treated explicitly
and more importantly, transparently. If that's part of it, say so.

> _With some difficulty_ the modules got switched over (i.e. footnote two
> from your email), which makes me question the non-trivial time
> investment it will take to switch over everything completely.
>
> >
> > Note that noting is set in stone, and everything is freely debatable.
>
> I'm not in favor of the transition from CVS to SVN. For one, I've just
> started to get the hang of CVS :), and would rather not have to spend

There are ways to transparently and bidirectionally interfacing the two,
but I haven't seen mention of Marc setting this up as well. I have seen
instructions indicating that this hasn't been done, but I could have
missed something...

> time learning a new system and program. I'm also having a hard time
> seeing the point of investing time in changing something that seems to
> work fine already (not just my time, mind you, but everyone's). Just my
> two cents on the matter, though.
>

My tuppence as well, if it hasn't been devaluated (what with the
dollar's demise and all)

Regards
-MG
Received on Fri Apr 8 07:35:47 2005

This archive was generated by hypermail 2.1.8 : Fri Apr 08 2005 - 07:35:48 CEST