Moving from cvs to subversion

[Asiel Brumfield]

Sourceforge has announced they now have subversion availibility. I think we should try to move from cvs to subversion as soon as possible. There will be several benefits to our project over cvs that I have listed below. I have also included the text from the e-mail sent by sourceforge so you can see all the new features.

Some of the biggest benefits that I see immediately are:

No sync delay between developer and anonymous access.
Self-service backups and mirroring
Commit e-mail support.

What are others feelings on making this move?

Asiel

Sourceforge e-mail text:


Subversion General Availability
------------------------------

-

The SourceForge.net team is pleased to announce the General Availability
of Subversion service to SourceForge.net-hosted projects, effective
2006-02-21. This service offering is in addition to our existing CVS
service; as with all of our services, projects may select (and enable in
the project admin pages) the portion of our offering that best meets
their needs.

We wish to extend our thanks to the many projects and developers who
have helped us to test our Subversion service as part of our six-week
beta, which completed last week. Our particular thanks go to these
projects, whose members provided substantial feedback regarding the
new service:

* Inkscape - http://sourceforge.net/projects/inkscape/
* DejaVu Fonts - http://sourceforge.net/projects/dejavu/
* ScummVM - http://sourceforge.net/projects/scummvm/
* evilnet - http://sourceforge.net/projects/evilnet/


Our Subversion service includes:

SSL-based Repository Access:
* Developer Subversion access via HTTPS, auth is requested when you
perform a write operation
* Anonymous Subversion access via HTTPS
* No sync delays between developer and anonymous Subversion access
* Per-developer access control over repository access (ACL support to be
added in the future) via the SourceForge.net permissions system

Web-based viewing:
* Web-based repository access via ViewVC (formerly known as ViewCVS)

On-demand self-service backups and mirroring capability:
* Read-only rsync access to the repository to permit backups and
remote mirroring

Ease of migration:
* Automated self-service migration of your SourceForge.net project CVS
repository, CVS tarball, or Subversion dump to our Subversion service

Well-considered add-ons to basic service:
* A selected set of hook scripts, including commit email support and
CIA bot support
* Statistics tracking of Subversion repository activity


Service may be enabled by project administrators in the "Subversion"
section of the Project Admin pages.

Complete service documentation is available at:
http://sf.net/docs/E09/

Documentation is provided for supported clients at:
http://sf.net/docs/F06/ for the command-line SVN client
http://sf.net/docs/F07/ for TortoiseSVN

Our support of Subversion has been based on substantial research and
testing in the past few months, which we have pursued specifically based
on requests from the community. SourceForge.net continues to consider
new technologies and evaluate community requests in further
strengthening our service offering.

--
Asiel

[Greg Blaire]

You guys have been using CVS for a while and I’m new to it.  But I like subversion – maybe because I’m more familiar to it.

 

---

[Martin Havlat]

I looked at http://wiki.gnuarch.org/SubVersionAndCvsComparison
I have not experience with subversion, but it seems similar to CVS and
there are certain benefits. I hope that the project has some similar
client with GUI as is WinCVS. Do you have some experience?

I think that the main priority is coding 1.7 now. So I see better to
plan such action to some milestone as is 1.7.0 release.

Regards,

Martin

Greg Blaire wrote:
> You guys have been using CVS for a while and I’m new to it. But I like
> subversion – maybe because I’m more familiar to it.
>
>
>

> ------------------------------------------------------------------------
>
> *From:* testli...@googlegroups.com
> [mailto:testli...@googlegroups.com] *On Behalf Of *Asiel Brumfield
> *Sent:* Monday, February 27, 2006 10:28 AM
> *To:* testlink-dev
> *Subject:* Moving from cvs to subversion

> http://sf.net/docs/E09/ <http://sf.net/docs/E09/>

>
> Documentation is provided for supported clients at:
> http://sf.net/docs/F06/ for the command-line SVN client
> http://sf.net/docs/F07/ for TortoiseSVN
>
> Our support of Subversion has been based on substantial research and
> testing in the past few months, which we have pursued specifically based
> on requests from the community. SourceForge.net continues to consider
> new technologies and evaluate community requests in further
> strengthening our service offering.
>
>
>
> --
> Asiel
>
>
>

This e-mail and any attachment is for authorised use by the intended recipient(s) only. It may contain proprietary material, confidential information and/or be subject to legal privilege. It should not be copied, disclosed to, retained or used by, any other party. If you are not an intended recipient then please promptly delete this e-mail and any attachment and all copies and inform the sender. Thank you.

[Asiel Brumfield]

Martin,

There are many gui tools similar to wincvs and other common cvs tools.

Some resources you might want to take a quick look at are:
http://tortoisesvn.sourceforge.net/ - tourtise svn client a good replacement for wincvs
http://svnbook.red-bean.com/ - the subversion book

There is a great deal of documentation available online for subversion so I don't think answering any of our questions should be a problem.
I think the benefits of moving to subversion now outweigh the downsides. If you are using a graphical client or an IDE plugin to do your checkins the change should be almost transparent to you once you have updated your graphical client and/or IDE plugin. If you are using the command line client to manage your checkins it will be a slightly greater learning curve. This will be eased by the good documentation out there though.

Asiel

[Schlundus]

> I think that the main priority is coding 1.7 now. So I see better to
> plan such action to some milestone as is 1.7.0 release.

Yes, no need to act now!
Bye

[Asiel Brumfield]

One of the main reasons I suggest we make this move now rather than later is that it will greatly benefit our 1.7 release. We will save time with the new features and cut out many of the needless things we currently do. I have setup a testlink-commits mailing list which we can send e-mails to for each subversion commit. Then each of us can subscribe to a daily e-mail digest or each e-mail to get these commit e-mails automatically. This benefit alone will save us lots of time and will be far more consistent. We won't have to read multiple e-mails about simple commits if we don't want to. We also don't have to worry about manually sending out an e-mail each time we commit. We will also get the benefit of no delay between checkins and anonomyous access. This means users will be able to be sure they are checking out the same code as us. It also means if we use the web interface to view cvs checkins of diffs etc. it will be in sync rather than several hours behind like with cvs. There are many other benefits too. I think that making this move is well worth the small amount of effort required on the developer end. If we wait till 1.7 is out then we are just working around the system still and not getting any of these benefits until after this major release.

Asiel

[jbett...@gmail.com]

Hi...

My name is Jared Betteridge and I use TestLink in my job as a QA
Engineer. I've been following this list for a little while as I'd like
to eventually contribute to this great project. I'd just thought I'd
chime in on this dicussion as someone who has used both CVS and
Subverision. I think Subversion is much nicer than CVS, and if you
aleady know CVS it is very easy to learn, so I say go for it now!

Also separating the commits out to a different list is a great idea. I
have a hard time following this list with all the commit messages mixed
in.

Jared Betteridge

[Kevin Levy]

Please push all administrative changes to post 1.7.  Websites/tools/whatever - should take a back seat to people coding and testing.

 

Kevin

[Asiel Brumfield]

We should wait for some (probably even most) changes. In this case though there are signifigant benefits with very little downside. I'm only suggesting this as it will help improve our development process for 1.7 and going forward.

Waiting to make this change till 1.7 is finished, which is likely at least 6 months out would be unfortunate. I think this is the case because we have the opportunity to do something that is fairly simple that will greatly improve our process and make everyones lives a little bit easier while doing testlink development. If this were something that would take even one person several days I would agree with you. However, this is not the case. So I think we should go for it and start reaping the benefits now rather than later.

I agree with you that coding/testing should be top priority for 1.7. If there are simple things we can do that will make development and testing activities easier, we should do them! I want to get the most productivity out of the time I spend working on testlink. I'm sure this is the same with everyone else, and this is why making these type of changes just makes sense. Over the course of the development of 1.7 I'm certain that we will all save far more time than we will lose from making this move now.

Asiel

[Martin Havlat]

Thank you all for the discussion. I summarize: Nobody have a problem to
move under Subversion. The current core developers and me would like to
do this later.
1.7 was example I wrote. It could be earlier, for example for RC1.
Asiel, I'll assign this task in dotProject to you with dependency to
RC1. Feel free to reassign back, if you disagree.

Martin

Asiel Brumfield wrote:
> We should wait for some (probably even most) changes. In this case
> though there are signifigant benefits with very little downside. I'm
> only suggesting this as it will help improve our development process for
> 1.7 and going forward.
>
> Waiting to make this change till 1.7 is finished, which is likely at
> least 6 months out would be unfortunate. I think this is the case
> because we have the opportunity to do something that is fairly simple
> that will greatly improve our process and make everyones lives a little
> bit easier while doing testlink development. If this were something that
> would take even one person several days I would agree with you. However,
> this is not the case. So I think we should go for it and start reaping
> the benefits now rather than later.
>
> I agree with you that coding/testing should be top priority for 1.7. If
> there are simple things we can do that will make development and testing
> activities easier, we should do them! I want to get the most
> productivity out of the time I spend working on testlink. I'm sure this
> is the same with everyone else, and this is why making these type of
> changes just makes sense. Over the course of the development of 1.7 I'm
> certain that we will all save far more time than we will lose from
> making this move now.
>
> Asiel
>

> On 3/1/06, *Kevin Levy* < kevi...@hotmail.com

[Francisco Mancardi]

As said before I have loose a lot of mail and I don't know why.
Thats why I'm replying now.
1. About subversion:
I vote NO (and I'm one of the current core developers).
Till now we have had no problems with CVS, then I see no reason to
spend
time struggling with Subversion.
Again I've stated in earlier discussion I see people (this case Asiel)
too eager to use new tools IMHO just to use the new things.
I'm not saying I will not want to use Subversion in the future (and the
future is NOT RC1, may be 1.9), just that now our efforts
and priorities must be focuses on creating TL 1.7, and there is a lot
of work to do.

2. Regarding to send commit info to other list, again disagree, I want
to inform
what is happen to the developers (and be informed), as I was done
before using
the list.
Again see no need to open another list, just more work (any time I need
to send
a mail to TL need to chose between to e-mail addresses).
I'm not doing this for living means I need to work in this project in
the easier way.

Regards

Francisco

[Asiel Brumfield]

Replies inline below.

On 3/10/06, Francisco Mancardi <francisco...@gruppotesi.com> wrote:

As said before I have loose a lot of mail and I don't know why.
Thats why I'm replying now.
1. About subversion:
I vote NO (and I'm one of the current core developers).
Till now we have had no problems with CVS, then I see no reason to
spend
time struggling with Subversion.
Again I've stated in earlier discussion I see people (this case Asiel)
too eager to use new tools IMHO just to use the new things.

This is not a case of wanting to use new tools just to use new tools. There are multiple significant benefits from moving to subversion. I have pointed out the specific benefits that would be good for everyone on the project. Do you contest that these benefits are not true? Or have you just not bothered to actually read my previous e-mails?

What are the struggles you are referring to? The switch to subversion should require very little effort on any of our parts. If you are using an IDE or graphical client it is simply a matter of installing a new client or plugin. If you are using the cli to do cvs, svn is very similar and the minimal differences should be easy to learn as you are used to using cli tools. I don't see this as a struggle. It should take less than 30 minutes of your time at most, and will provide multiple long term benefits.

What specific tools are you referring to that I want to add just to use new things?

You trying to insult me by saying these type of things is getting a little old. You never point to any specific evidence to support your claims, you just make overly broad statements. I cannot see any other intention of these type of comments than to try and take a cheap shot. If you want to discuss this please do with facts, not baseless claims. Please point to even one case that supports your claim, as I have yet to hear anything but your personal opinion.

I'm not saying I will not want to use Subversion in the future (and the
future is NOT RC1, may be 1.9), just that now our efforts
and priorities must be focuses on creating TL 1.7, and there is a lot
of work to do.

2. Regarding to send commit info to other list, again disagree, I want
to inform
what is happen to the developers (and be informed), as I was done
before using
the list.

This is exactly what the other list would accomplish. You would actually be more informed than you currently are. In addition, you could choose to receive a daily digest e-mail instead of every single e-mail. Also, you could use your e-mail client to filter e-mails such as this separately from commit e-mails. I don't know about you, but I get a lot of e-mail, and looking at many commit e-mails each day that I could get in a single e-mail seems like a waste to me. On top of this, I know that our e-mails don't actually always detail everything we have done. With automatic commit e-mails that I'm talking about we never have to send e-mails manually and the information is always accurate.

Again see no need to open another list, just more work (any time I need
to send
a mail to TL need to chose between to e-mail addresses).

This is the point! You wouldn't have to send a separate e-mail anymore. Less work. Everything would be fully automatic based on our commits.

If you do choose to send another e-mail manually, is it really that hard to send it to a different address? You already send an e-mail that is separate from anything else. You are just changing the address.

[Greg Blaire]

Hi Francisco,

I'm not sure if you've used subversion before, but maybe your resistance is due to time constraints.  But Subversion is VERY similar to CVS there really isn't any learning curve.  And it really is fully featured.

If sourceforge already has the infrastructure in place at the very least someone should test what they've got to make sure they're implementation is something you core developers can live with.  Importing this project is a snap.  I've used both CVS and Subversion and we chose subservion for its ease of use, compared to CVS and all of its features.

There really are truly benefits to moving to Subversion, its not just a 'new technology' thing.

My .02 cents.

[Francisco Mancardi]

> Hi Francisco,
>
> I'm not sure if you've used subversion before, but maybe your resistance is
> due to time constraints.

Yes. We have enough problems with time now to start with new ones
regarding
a new tool

>But Subversion is VERY similar to CVS there really
> isn't any learning curve. And it really is fully featured.
>

One year ago I've look at Subversion, downloaded and read the book.
I think is good but, just let me know if now Subversion solves problems
that are
critical now to our project.
IMHO that's the point, if solve important problems we can choose to
invest on it
but if not, I see no need to do nothing.

Again: I HAVE NO PROBLEM TO USE SUBVERSION IN THE FUTURE, but THE
FUTURE IS NOT (at least for me) the following 2 month.

Asiel said this are the advantages:
1. No sync delay between developer and anonymous access.
I don't see this is critical

2. Self-service backups and mirroring
this can be interesting, but nothing that a good script can't do

3. Commit e-mail support.
It would be great if this has been explained better, now I need to
look
for the info, to understand how it works.
If you try to sell me something, it's better if you explain me how
this will ease my work

Then IMHO this 3 features has not enogh value to made the change.

> If sourceforge already has the infrastructure in place at the very least
> someone should test what they've got to make sure they're implementation is
> something you core developers can live with. Importing this project is a
> snap. I've used both CVS and Subversion and we chose subservion for its
> ease of use, compared to CVS and all of its features.
>
> There really are truly benefits to moving to Subversion,

Please (I don't want to be rude) give me facts no words, what features
of subversion will be now to important to do the switch . ???

Again, after the release of 1.7 we can think about this.

>its not just a 'new
> technology' thing.

I repeat again NOW on this moment is just 'new technology' thing.

Regards

Francisco

>
> My .02 cents.
>

[Asiel Brumfield]

Does anyone else have opinions on this? I think waiting 10+ months to make this change is a huge mistake. If you don't see the benefits yet I've listed multiple resources outside of my own opinions to back up my claims below.

------------------------------------------------------

Some other benefits of subversion over cvs are listed in the following places:
http://en.wikipedia.org/wiki/Subversion_(software)#Advantages_over_CVS
http://www.co-sage.org/presentations/Feb2004/CoSAGE-Subversion.pdf
http://www.jini.org/docs/cvs_vs_subversion.pdf
http://developers.slashdot.org/article.pl?sid=05/05/04/136257&from=rss

Also some comments from other open source projects much larger than testlink that have made the switch:

KDE:
Subversion offers many advantages over CVS while remaining similar enough to use that it should be easy for existing users to learn. Changes are now made with a single revision number per-commit rather than per-file. It also offers the ability to move files & directories and makes it easier to work with branches.

------------------------------------------------------

If you have comments on this it would be nice to know. Maybe as a team we can take a vote for when we want to make this change. This seems to be the only appropriate choice since we really have no concept of a project leader that would make these type of decisions. So if everyone could vote we can make a decision once and for all and go through with whatever we decide collectively.


Asiel

[Greg Blaire]

I'm sorry for weighing in on this again. But I think everyone is making a
big deal over nothing.

Subversion is just like CVS, but better. And the import process will be a
snap. It shouldn't contribute to any downtime. I honestly don't see a
downside. I think we've spent more time chattering about it than it would
take to start using it.

I think we should try someone's implementation of Subversion so the core
developers can get comfortable with it.

But if the core developers so no, that should be the end of it and we'll
wait until they're ready. This decision wouldn't prevent us from using SVN
on our own.

Regards, Greg

-----Original Message-----
From: testli...@googlegroups.com [mailto:testli...@googlegroups.com]

On Behalf Of Francisco Mancardi
Sent: Saturday, March 11, 2006 1:04 AM
To: testlink-dev
Subject: Re: Moving from cvs to subversion

[Martin Havlat]

I hope that this discussion was closed for now.
The moving to Subversion could be done after code will be stable.

Martin