Re: [vhdl-200x] Code sharing options

Hi Martin,
Add one more (I think this is also distributed, after reading your
description):
* TortoiseSVN

TortoiseSVN is a client-side software (and it's free, as in beer). At the
server side, I'm not quite sure, but my guess is that they can use
Subversion (or any Subversion-like) repository. It also has some of the
features you mentioned (Windows Explorer integration, automatic merging,
diff, etc.). When a client checks out a project, he/she will have a copy of
the repository on his local drive and can make as many number of changes
before he becomes satisfied to check his changes back to the main
repository.

I guess there are other good Subversion clients (other than TortoiseSVN),
and hopefully, they too provide distributed computing.

"* Platforms:
  - Is good Windows support important?
  - Is good Mac support important?
  - Is good Linux (other Unix?) support important?"
To me (my own personal opinion), at least good Unix and Windows support will
be great. If we choose one distributed solution that also has a central
server (like Git or Subversion/TortoiseSVN), the server can be Unix, while
the clients can either be Unix, Windows, or Linux (or even Mac).

"Alternatively:
* we could set up our own server.
* we could just all have our own local repositories and pull changes from
each other (the Linux kernel is developed like this)."
Actually I like this idea. But that's because I have a homeserver (just a
laptop actually) running on OpenSolaris, which uses the ZFS filesystem (and
can pull changes from each other just like a version control system).
However, there may be others who may only have Windows. I guess we need to
think about them as well.
Probably a central Unix server which supports Windows and Unix clients will
be a good start.

Regards,
Daniel

On Tue, May 3, 2011 at 7:55 PM, Martin.J Thompson <Martin.J.Thompson@trw.com
> wrote:

> Hi all,
>
> In last weeks' confcall I was asked to put together a list of potential
> code-sharing/revision-control options. Code-sharing is much more what we're
> about (to my mind), revision control comes as a necessary element.
>
> Fair warning, this email is quite long. And it may feel like teaching some
> of you to "suck eggs" (as the saying goes) - apologies for that, but I hope
> there will be something new for everyone :) At the end there's a set of
> questions we should answer to move on. I should also point out that this is
> all my own thoughts and should not be construed as anything representing
> TRW's corporate ways or thinking!
>
> To start with, there are two sorts of code sharing to consider: centralised
> and distributed.
>
> In the old days, we only had centralised systems - CVS, Subversion, Visual
> Sourcesafe are examples. There's a central server, you check code out from
> it and you send new code back to it. In some cases, when you had code
> checked out, it was locked, no-one else could also work on it. There were
> no merging problems, as only one developer could modify a given file
>
> Distributed revision control systems keep a copy of the entire repository
> for a project locally to the user. They can make changes against that
> repository and the distribute those to other developers in various ways -
> they can pull changes from others' repositories into theirs.
>
> Some distributed systems can *also* have a central server, so that when
> you're happy with your local branch you can "push" your changes to the
> server and they will be included next time another users decides they want
> an update from that server and "pulls" it into their project.
>
> Further reading: http://en.wikipedia.org/wiki/Distributed_revision_control
>
> Other useful features which can come with code-sharing systems are:
> * Web based interfaces
> * Windows Explorer integration
> * Mac Finder integration
> * Code review (by email or online)
> * Automatic merging of branches
>
> Personally, having worked on an (open source) project distributed across
> countries with a number of developers, distributed version control is
> brilliiant. We also ran it in tandem with enforced code review by a
> rigorous core group which ensured that coding standards were followed. This
> produced readable and clean code which wasn't obviously written by a whole
> gang of different people with different ideas of how to lay code out. It
> makes it much more accessible - once you have more than one developer, I
> think this is crucial.
>
> I would propose that we look at a distributed solution - three candidates
> spring to mind (in that I've used them or considered using them):
> * Git - written to manage the linux kernel. It's *very* fast, but works
> bit differently to other systems. http://git-scm.com/
> * Bazaar - Supported by Canonical (of Ubuntu Linux fame). Feels a bit more
> "familiar" compared to Git. http://bazaar.canonical.com/
> * Mercurial - I haven't used this, it seems to be simpler in terminology to
> Bazaar, also is familiar feeling. http://mercurial.selenic.com/
> * DARCS - I considered this a long while ago, but discarded it as "too
> Unixy" for my potential users. I haven't looked at it since...
>
> Anyone else have any other suggestions?
>
> Where to host:
> =========
> * Github (hosts git repositories, surprisingly enough). I've used this a
> bit for personal stuff. https://github.com/
> * Launchpad (Bazaar repositories). I've used this for opensource projects.
> https://launchpad.net/
> * bitbucket (Mercurial repositories). No experience.
> https://bitbucket.org/
> * Kiln (Mercurial again). I've read about it.
> http://www.fogcreek.com/kiln/
>
> Features:
> - All have web front ends.
> - Launchpad (and Kiln I think) offer review-flow management (a flow like:
> developer makes a branch for a specific update, makes changes, submits
> changes for review, iterate until reviewers happy, commits to trunk).
> Github has partial code review in the "fork queue". Bitbucket (as far as I
> can tell) offers visual code diffing, which can be used for a manual review
> process with reviewers sending emails back and forth and deciding by email
> when code should be accepted.
> - Launchpad, Github and Bitbucket have bug trackers. Kiln can add this
> feature (for a cost).
> - Launchpad has specification tracking
>
> Alternatively:
> * we could set up our own server.
> * we could just all have our own local repositories and pull changes from
> each other (the Linux kernel is developed like this).
>
> Prices:
> ====
> The license under which our code is published is very significant. If it's
> an "approved" open-source license, then all - except Kiln - of these
> providers will offer free hosting. If we count as a non-profit, then all of
> them may offer us a free-account.
>
> What are people's opinions on applying open-source licenses for "VHDL core
> language elements" and for "libraries that would be useful"? (Some
> discussion has already been held here:
> http://www.tekphile.com/2010/12/where-is-vhdls-jquery/ )
>
> If the code has a commercial (or otherwise restrictive) license, my
> understanding it that someone will have to pay (although bitbucket seems to
> offer a 5 user system for free).
>
> Some pricing (based on my guesses as to our needs):
>
> * Github $12-$22/month, 5-10 users or $25-$200/month for a "business"
> account.
> * Launchpad - no details on web have to email commercial@launchpad.net -
> maybe free for non-profits?
> * Bitbucket - $10-$20/month (10-25 users) - may qualify for a "non-profit"
> free account?
> * Kiln - $25/user/month (!)
>
> Requirements capture:
> ==============
> Can we answer these questions?
>
> * Number of collaborators (ie users)
> * Number of "sub-projects"
> * What license will we publish under?
> * Do we want code review tools?
> * Do we want code review formalised?
> * Do we prefer any of the tools I've mentioned (or any others)
> * Platforms:
> - Is good Windows support important?
> - Is good Mac support important?
> - Is good Linux (other Unix?) support important?
>
> And anything else anyone wants to add!
>
> I think it'd be great to have lots of people collaborating on things like
> Jim's random library, Dave's math-related libraries and anything else that
> the community could reuse!
>
> Cheers,
> Martin
> (again - not speaking for TRW!)
> --
>
> Martin Thompson CEng MIET
> TRW Conekt, Stratford Road, Solihull, B90 4GW. UK
> +44 (0)121-627-3569 : martin.j.thompson@trw.com
> http://www.conekt.co.uk/
>
> Conekt is a trading division of TRW Limited
> Registered in England, No. 872948
> Registered Office Address: Stratford Road, Solihull B90 4AX
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.