Curtis Olson wrote:
On Wed, Sep 2, 2009 at 2:02 PM, Tom P <[email protected]
<mailto:[email protected]>> wrote:
Hi Curt
My only concern with SVN is that it stores every file twice in the
local file system, so it's not ideal for the 'data' portion of
FlightGear. For example, right now a complete checkout of Aircraft
is ~ 2 GB, and it would double overnight.
A quick check of the 'data' repository reports it's size is about
5Gb. Presumably with a distributed source code control system, each
end user would be downloading this much data + the disk space foot
print would be at least this much (+ maybe the extra 2Gb for a working
copy?)
Yes, I agree, a distributed system is overkill for the data portion.
But for source, it's VERY powerful and convenient, and the fact that it
doesn't scatter CVS or .svn directories all over the tree is a major
plus in my eye.
Is this an argument to stay with CVS for the data portion of the project?
Well, it's more an argument in favor of splitting the data and source
code, like it's already the case for the Scenery
http://code.google.com/p/terrascenery/
Because the two sets seem to have different requirements when it comes
to revision control.
1) data is handled well by a lightweight client-server model (either CVS
or SVN) that:
- allows users and developers to synchronize their local data set,
simply and quickly
- for updates, the UI is very simple
- the client is available as a library and can be embedded inside
tools like 'terrasync'
- the repository has a small footprint on the local system (ok, SVN is
not ideal, but still manageable)
- doesn't need advanced support for branching and merging
- doesn't need local access to the entire project history
2) source can be handled equally well with a centralized server model or
with a distributed one, but as FG development evolves, the requirements
will grow from basic centralized revision control to:
- advanced branching and merging
- completely unplugged operation
(very nice, you can code on your laptop and have the entire project
history at your fingertips)
- support for a work-flow where many developers don't have commit
access to the central repository and send patches
This is a good point to bring up though in advance. The default
project quota at code.google.com <http://code.google.com> (is there a
shorter abbreviation?) is 1Gb so we'd be fine for SimGear and
FlightGear code, but we'd blow way over that for data.
terrascenery is hosted on code.google.com, and that's way above 1 GB, so
Google probably waives the limit for specific projects.
I know, disk space is cheap in these days, but the double-write
also results in slower checkouts.
In other words, I think we should import FlightGear as well into
code.google.com <http://code.google.com> and see if we are happy
with the performance before jumping.
Part of the goal of my original post was to have people take a look at
SimGear in google/svn form to see if there were any major oversights
in the migration process before we make any actual move. But
certainly the large size of the data is an additional dimension to test.
I'm available to test a SVN FlightGear repo on code.google.com if you
have the time to import from CVS.
I can benchmark checkout times and disk usage and provide a comparison
between CVS, SVN and the GIT repositories.
Just let me know, thanks.
Apart from this concern, I've used CVS, SVN and GIT and I'm not
religious about the choice.
In the end, any tool will work as long as it's:
- fast
- easy to use
- well integrated with other tools like bug tracking SW <-----
and this is very important IMHO
(you have bugs referring to check-ins, check-ins referring to
bugs, RSS feeds of changes, etc ...)
I noticed google has an interesting system (which I haven't explored
in detail) that allows users to rate individual commits as positive,
neutral, or negative, with the option to leave comments. Any changes
to the tools also implies some changes to the typical workflow, but
code.google.com <http://code.google.com> has some nice features.
Yep, by switching we would get a nice issue tracker, I think it could be
a huge improvement for the project.
It also supports mercurial (hg) which might be an option for the
future if we decide a distributed source code management system is the
better way to go.
And here's a page comparing SVN, GIT and Mercurial. It's light on
details but might help a bit with the decision:
http://www.russellbeattie.com/blog/distributed-revision-control-systems-git-vs-mercurial-vs-svn
Regards,
Curt.
--
Curtis Olson: http://baron.flightgear.org/~curt/
<http://baron.flightgear.org/%7Ecurt/>
------------------------------------------------------------------------
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
------------------------------------------------------------------------
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Flightgear-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/flightgear-devel
