Re: cvs vs. svn vs. git

Phil Endecott schrieb:
> Hi Denis,
> 
> First, congratulations on releasing DirectFB 1.0.  I
had a quick look at 
> the list archives (I'm not currently subscribed, though
I have been in 
> the past) expecting to see a long thread about it, but
it seems the 
> milestone has not been commented on!

Thanks for your mail 

> Anyway while I was browsing I saw the thread about
moving to git and I 
> thought I'd share my experience when I saw this
comment:
> 
>> I like distributed repositories. At the moment I'm
having
>> different CVS repositories for different projects,
each
>> having its own DirectFB module. Merging between
them is
>> always done manually with cvs diff and patch etc.
>>
>> How would svn solve that?
> 
> The answer is "with svn:externals".  Although
I use subversion I do 
> understand that there are situations where git is more
suitable.  The 
> obvious case is when you have large numbers of
developers working very 
> independently.  I don't know if that applies to you. 
But in the case 
> that you describe, I have to ask, why does each of your
projects have 
> its own copy of DirectFB?  Personally, I would have a
single svn 
> repository for DirectFB.  Then in each of the other
projects, use an 
> svn:externals "symlink" to point to it.  When
you check out the project, 
> you'll get a copy of DirectFB automatically.

Is it possible to commit to the local copy and have your
local history?

How would you merge back your changes to the mainline?

> Another answer is to put all of the projects in a
single repository and 
> use "svn copy".
> 
> I thought I ought to write in case you weren't aware of
these Subversion 
> feature.  Perhaps git still suits you better.  But as a
DirectFB user, 
> my preference would be to avoid git for the following
reason: a git 
> checkout contains the complete history of the project. 
So if I want, 
> for some reason, to download the current state of the
project -
> 
> - With CVS I would download N megabytes and occupy N
megabytes of disk 
> space.
> - With Subversion I would download N megabytes and
occupy 2N megabytes 
> of disk space (it keeps a copy of the last checked out
version so that 
> "svn diff" can be fast).
> - With git I would download n*N megabytes and occupy
n*N megabytes of 
> disk space - what n would be I don't know, but I would
guess that it 
> would grow quite large.
> 
> I hope this is of some use.  I'm not an expert, but I
have had to make 
> this decision for open-source and
"real-world" projects recently.  Do 
> forward this to the list if you want.  I'm too lazy to
subscribe just to 
> post one message...

-- 
Best regards,
   Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/
                |
"------------------------------------------"

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

Phil Endecott schrieb:
> Denis Oliver Kropp wrote:
>>>> I like distributed repositories. At the
moment I'm having
>>>> different CVS repositories for different
projects, each
>>>> having its own DirectFB module. Merging
between them is
>>>> always done manually with cvs diff and
patch etc.
>>>>
>>>> How would svn solve that?
>>>
>>> The answer is "with svn:externals". 
Although I use subversion I do 
>>> understand that there are situations where git
is more suitable.  The 
>>> obvious case is when you have large numbers of
developers working 
>>> very independently.  I don't know if that
applies to you.  But in the 
>>> case that you describe, I have to ask, why does
each of your projects 
>>> have its own copy of DirectFB?  Personally, I
would have a single svn 
>>> repository for DirectFB.  Then in each of the
other projects, use an 
>>> svn:externals "symlink" to point to
it.  When you check out the 
>>> project, you'll get a copy of DirectFB
automatically.
>>
>> Is it possible to commit to the local copy and have
your local history?
>>
>> How would you merge back your changes to the
mainline?
> 
> If you really want to have separate history for each
project's version 
> of DirectFB, then you need to have multiple branches in
the DirectFB 
> repository.  Each project's external points to its own
branch of 
> DirectFB.  Then commits go into the branches.  To merge
a branch into 
> the trunk, in a checkout of the DirectFB trunk you
merge in the changes 
> from the branch and then commit.

But commits to the branch still require a connection to the
server and
don't go to the local disc, do they?

> I have a similar situation with a library of utility
functions that is 
> shared between a handful of projects.  I have embedded
the library into 
> the projects using externals.  I have not found it
necessary to have 
> multiple branches of the library, though at any point
in time each 
> project may have a different version of it checked out,
because 
> development on it is linear rather than branch/merge.
> 
> Again, I don't really know much about what you need to
do and maybe git 
> is best.  But I thought I ought to point out another
option.

-- 
Best regards,
   Denis Oliver Kropp

.------------------------------------------.
| DirectFB - Hardware accelerated graphics |
| http://www.directfb.org/
                |
"------------------------------------------"

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

Denis Oliver Kropp wrote:
> Phil Endecott schrieb:
> >> I like distributed repositories. At the moment
I'm having
> >> different CVS repositories for different
projects, each
> >> having its own DirectFB module. Merging
between them is
> >> always done manually with cvs diff and patch
etc.
> >>
> >> How would svn solve that?
> > 
> > The answer is "with svn:externals". 
Although I use subversion I do 
> > understand that there are situations where git is
more suitable.  The 
> > obvious case is when you have large numbers of
developers working very 
> > independently.  I don't know if that applies to
you.  But in the case 
> > that you describe, I have to ask, why does each of
your projects have 
> > its own copy of DirectFB?  Personally, I would
have a single svn 
> > repository for DirectFB.  Then in each of the
other projects, use an 
> > svn:externals "symlink" to point to it. 
When you check out the project, 
> > you'll get a copy of DirectFB automatically.

I use svn at work, and svn:externals doesn't what Dok wants
-- it's
just a means to check out or update multiple trees with one
command (e.g. you could set up a "dfb-all"
directory and set the
svn:externals property to check out DirectFB, FusionSound,
SaWMan, ...
in one go). The downside is that svn does no sufficient
error checking,
so you usually don't notice right away if something wnet
wrong.
svn:externals is similar to cvs modules (the CVSROOT/modules
file).

> Is it possible to commit to the local copy and have
your local history?

No.

> How would you merge back your changes to the mainline?

svn handles merges only within one repository.

svk extends svn with distributed features, but when I
tested
it last year it was incredibly slow and thus unusable.
(I tried to create a clone of the svk repo using svk and
killed it after one hour.)


Regards,
Johannes

_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev

On Tue, 06 Mar 2007 18:16:16 +0100, Denis Oliver Kropp
wrote:
> Phil Endecott schrieb:
>> - With CVS I would download N megabytes and occupy
N megabytes of disk 
>> space.
>> - With Subversion I would download N megabytes and
occupy 2N megabytes 
>> of disk space (it keeps a copy of the last checked
out version so that 
>> "svn diff" can be fast).
>> - With git I would download n*N megabytes and
occupy n*N megabytes of 
>> disk space - what n would be I don't know, but I
would guess that it 
>> would grow quite large.

The git repository can actually be very efficiently
compressed; with my
copy of the git Linux kernel repository, 'n' is only about
1.5 (so it's
even less than svn that weighs in at about 2.0!) in spite of
the fact that
it contains _all_ changes made to that rather largish
project since april
2005.

Numbers:
- the kernel source tree currently occupies 374MiB (without
git)
- the underlying .git repositiory occupies 187MiB (!)

Just my 0.02¤

Cheers
 Anders


_______________________________________________
directfb-dev mailing list
directfb-devdirectfb.org
http://mail.directfb.org/cgi-bin/mailman/listinfo/
directfb-dev