Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-01-28 11:29:49 -0500, Bruno Medeiros 
 said:


I've also been mulling over whether to try out and switch away from 
Subversion to a DVCS, but never went ahead cause I've also been 
undecided about Git vs. Mercurial. So this whole discussion here in the 
NG has been helpful, even though I rarely use branches, if at all.


However, there is an important issue for me that has not been mentioned 
ever, I wonder if other people also find it relevant. It annoys me a 
lot in Subversion, and basically it's the aspect where if you delete, 
rename, or copy a folder under version control in a SVN working copy, 
without using the SVN commands, there is a high likelihood your working 
copy will break! It's so annoying, especially since sometimes no amount 
of svn revert, cleanup, unlock, override and update, etc. will fix it. 
I just had one recently where I had to delete and re-checkout the whole 
project because it was that broken.
Other situations also seem to cause this, even when using SVN tooling 
(like partially updating from a commit that delete or moves 
directories, or something like that) It's just so brittle.
I think it may be a consequence of the design aspect of SVN where each 
subfolder of a working copy is a working copy as well (and each 
subfolder of repository is a repository as well)


Anyways, I hope Mercurial and Git are better at this, I'm definitely 
going to try them out with regards to this.


Git doesn't care how you move your files around. It track files by 
their content. If you rename a file and most of the content stays the 
same, git will see it as a rename. If most of the file has changed, 
it'll see it as a new file (with the old one deleted). There is 'git 
mv', but it's basically just a shortcut for moving the file, doing 'git 
rm' on the old path and 'git add' on the new path.


I don't know about Mercurial.

--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Jérôme M. Berger]

Michel Fortin wrote:
> On 2011-01-28 11:29:49 -0500, Bruno Medeiros
>  said:
> 
>> I've also been mulling over whether to try out and switch away from
>> Subversion to a DVCS, but never went ahead cause I've also been
>> undecided about Git vs. Mercurial. So this whole discussion here in
>> the NG has been helpful, even though I rarely use branches, if at all.
>>
>> However, there is an important issue for me that has not been
>> mentioned ever, I wonder if other people also find it relevant. It
>> annoys me a lot in Subversion, and basically it's the aspect where if
>> you delete, rename, or copy a folder under version control in a SVN
>> working copy, without using the SVN commands, there is a high
>> likelihood your working copy will break! It's so annoying, especially
>> since sometimes no amount of svn revert, cleanup, unlock, override and
>> update, etc. will fix it. I just had one recently where I had to
>> delete and re-checkout the whole project because it was that broken.
>> Other situations also seem to cause this, even when using SVN tooling
>> (like partially updating from a commit that delete or moves
>> directories, or something like that) It's just so brittle.
>> I think it may be a consequence of the design aspect of SVN where each
>> subfolder of a working copy is a working copy as well (and each
>> subfolder of repository is a repository as well)
>>
>> Anyways, I hope Mercurial and Git are better at this, I'm definitely
>> going to try them out with regards to this.
> 
> Git doesn't care how you move your files around. It track files by their
> content. If you rename a file and most of the content stays the same,
> git will see it as a rename. If most of the file has changed, it'll see
> it as a new file (with the old one deleted). There is 'git mv', but it's
> basically just a shortcut for moving the file, doing 'git rm' on the old
> path and 'git add' on the new path.
> 
> I don't know about Mercurial.
> 
Mercurial can record renamed or copied files after the fact (simply
pass the -A option to "hg cp" or "hg mv"). It also has the
"addremove" command which will automatically remove any missing
files and add any unknown non-ignored files. Addremove can detect
renamed files if they are similar enough to the old file (the
similarity level is configurable) but it will not detect copies.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 29/01/2011 10:02, "Jérôme M. Berger" wrote:

Michel Fortin wrote:

On 2011-01-28 11:29:49 -0500, Bruno Medeiros
  said:


I've also been mulling over whether to try out and switch away from
Subversion to a DVCS, but never went ahead cause I've also been
undecided about Git vs. Mercurial. So this whole discussion here in
the NG has been helpful, even though I rarely use branches, if at all.

However, there is an important issue for me that has not been
mentioned ever, I wonder if other people also find it relevant. It
annoys me a lot in Subversion, and basically it's the aspect where if
you delete, rename, or copy a folder under version control in a SVN
working copy, without using the SVN commands, there is a high
likelihood your working copy will break! It's so annoying, especially
since sometimes no amount of svn revert, cleanup, unlock, override and
update, etc. will fix it. I just had one recently where I had to
delete and re-checkout the whole project because it was that broken.
Other situations also seem to cause this, even when using SVN tooling
(like partially updating from a commit that delete or moves
directories, or something like that) It's just so brittle.
I think it may be a consequence of the design aspect of SVN where each
subfolder of a working copy is a working copy as well (and each
subfolder of repository is a repository as well)

Anyways, I hope Mercurial and Git are better at this, I'm definitely
going to try them out with regards to this.


Git doesn't care how you move your files around. It track files by their
content. If you rename a file and most of the content stays the same,
git will see it as a rename. If most of the file has changed, it'll see
it as a new file (with the old one deleted). There is 'git mv', but it's
basically just a shortcut for moving the file, doing 'git rm' on the old
path and 'git add' on the new path.

I don't know about Mercurial.


Mercurial can record renamed or copied files after the fact (simply
pass the -A option to "hg cp" or "hg mv"). It also has the
"addremove" command which will automatically remove any missing
files and add any unknown non-ignored files. Addremove can detect
renamed files if they are similar enough to the old file (the
similarity level is configurable) but it will not detect copies.

Jerome


Indeed, that's want I found out now that I tried Mercurial. So that's 
really nice (especially the "addremove" command), it's actually 
motivation enough for me to switch to Mercurial or Git, as it's a major 
annoyance in SVN.


I've learned a few more things recently: there's a minor issue with Git 
and Mercurial in that they both are not able to record empty 
directories. A very minor annoyance (it's workaround-able), but still 
conceptually lame, I mean, directories are resources too! It's curious 
that the wiki pages for both Git and Mercurial on this issue are exactly 
the same, word by word most of them:

http://mercurial.selenic.com/wiki/MarkEmptyDirs
https://git.wiki.kernel.org/index.php/MarkEmptyDirs
(I guess it's because they were written by the same guy)

A more serious issue that I learned (or rather forgotten about before 
and remembered now) is the whole DVCSes keep the whole repository 
history locally aspect, which has important ramifications. If the 
repository is big, although disk space may not be much of an issue, it's 
a bit annoying when copying the repository locally(*), or cloning it 
from the internet and thus having to download large amounts of data.
For example in the DDT Eclipse IDE I keep the project dependencies 
(https://svn.codespot.com/a/eclipselabs.org/ddt/trunk/org.dsource.ddt-build/target/) 
on source control, which is 141Mb total on a single revision, and they 
might change ever semester or so...
I'm still not sure what to do about this. I may split this part of the 
project into a separate Mercurial repository, although I do lose some 
semantic information because of this: a direct association between each 
revision in the source code projects, and the corresponding revision in 
the dependencies project. Conceptually I would want this to be a single 
repository.


(*) Yeah, I know Mercurial and Git may use hardlinks to speed up the 
cloning process, even on Windows, but that solution is not suitable to 
me, as I my workflow is usually to copy entire Eclipse workspaces when I 
want to "branch" on some task. Doesn't happen that often though.


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[David Nadlinger]

On 2/1/11 2:44 PM, Bruno Medeiros wrote:

[…] a direct association between each
revision in the source code projects, and the corresponding revision in
the dependencies project. […]


With Git, you could use submodules for that task – I don't know if 
something similar exists for Mercurial.


David

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[foobar]

Bruno Medeiros Wrote:

> On 29/01/2011 10:02, "Jérôme M. Berger" wrote:
> > Michel Fortin wrote:
> >> On 2011-01-28 11:29:49 -0500, Bruno Medeiros
> >>   said:
> >>
> >>> I've also been mulling over whether to try out and switch away from
> >>> Subversion to a DVCS, but never went ahead cause I've also been
> >>> undecided about Git vs. Mercurial. So this whole discussion here in
> >>> the NG has been helpful, even though I rarely use branches, if at all.
> >>>
> >>> However, there is an important issue for me that has not been
> >>> mentioned ever, I wonder if other people also find it relevant. It
> >>> annoys me a lot in Subversion, and basically it's the aspect where if
> >>> you delete, rename, or copy a folder under version control in a SVN
> >>> working copy, without using the SVN commands, there is a high
> >>> likelihood your working copy will break! It's so annoying, especially
> >>> since sometimes no amount of svn revert, cleanup, unlock, override and
> >>> update, etc. will fix it. I just had one recently where I had to
> >>> delete and re-checkout the whole project because it was that broken.
> >>> Other situations also seem to cause this, even when using SVN tooling
> >>> (like partially updating from a commit that delete or moves
> >>> directories, or something like that) It's just so brittle.
> >>> I think it may be a consequence of the design aspect of SVN where each
> >>> subfolder of a working copy is a working copy as well (and each
> >>> subfolder of repository is a repository as well)
> >>>
> >>> Anyways, I hope Mercurial and Git are better at this, I'm definitely
> >>> going to try them out with regards to this.
> >>
> >> Git doesn't care how you move your files around. It track files by their
> >> content. If you rename a file and most of the content stays the same,
> >> git will see it as a rename. If most of the file has changed, it'll see
> >> it as a new file (with the old one deleted). There is 'git mv', but it's
> >> basically just a shortcut for moving the file, doing 'git rm' on the old
> >> path and 'git add' on the new path.
> >>
> >> I don't know about Mercurial.
> >>
> > Mercurial can record renamed or copied files after the fact (simply
> > pass the -A option to "hg cp" or "hg mv"). It also has the
> > "addremove" command which will automatically remove any missing
> > files and add any unknown non-ignored files. Addremove can detect
> > renamed files if they are similar enough to the old file (the
> > similarity level is configurable) but it will not detect copies.
> >
> > Jerome
> 
> Indeed, that's want I found out now that I tried Mercurial. So that's 
> really nice (especially the "addremove" command), it's actually 
> motivation enough for me to switch to Mercurial or Git, as it's a major 
> annoyance in SVN.
> 
> I've learned a few more things recently: there's a minor issue with Git 
> and Mercurial in that they both are not able to record empty 
> directories. A very minor annoyance (it's workaround-able), but still 
> conceptually lame, I mean, directories are resources too! It's curious 
> that the wiki pages for both Git and Mercurial on this issue are exactly 
> the same, word by word most of them:
> http://mercurial.selenic.com/wiki/MarkEmptyDirs
> https://git.wiki.kernel.org/index.php/MarkEmptyDirs
> (I guess it's because they were written by the same guy)
> 
> A more serious issue that I learned (or rather forgotten about before 
> and remembered now) is the whole DVCSes keep the whole repository 
> history locally aspect, which has important ramifications. If the 
> repository is big, although disk space may not be much of an issue, it's 
> a bit annoying when copying the repository locally(*), or cloning it 
> from the internet and thus having to download large amounts of data.
> For example in the DDT Eclipse IDE I keep the project dependencies 
> (https://svn.codespot.com/a/eclipselabs.org/ddt/trunk/org.dsource.ddt-build/target/)
>  
> on source control, which is 141Mb total on a single revision, and they 
> might change ever semester or so...
> I'm still not sure what to do about this. I may split this part of the 
> project into a separate Mercurial repository, although I do lose some 
> semantic information because of this: a direct association between each 
> revision in the source code projects, and the corresponding revision in 
> the dependencies project. Conceptually I would want this to be a single 
> repository.
> 
> (*) Yeah, I know Mercurial and Git may use hardlinks to speed up the 
> cloning process, even on Windows, but that solution is not suitable to 
> me, as I my workflow is usually to copy entire Eclipse workspaces when I 
> want to "branch" on some task. Doesn't happen that often though.
> 
> -- 
> Bruno Medeiros - Software Engineer

You raised a valid concern regarding the local copy issue and it has already 
been taken care of in DVCSes:

1. git stores all the actual data in "blobs" which are compressed wherea

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Bruno Medeiros wrote:
A more serious issue that I learned (or rather forgotten about before 
and remembered now) is the whole DVCSes keep the whole repository 
history locally aspect, which has important ramifications. If the 
repository is big, although disk space may not be much of an issue,


I still find myself worrying about disk usage, despite being able to get a 2T 
drive these days for under a hundred bucks. Old patterns of thought die hard.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Jonathan M Davis]

On Tuesday, February 01, 2011 15:07:58 Walter Bright wrote:
> Bruno Medeiros wrote:
> > A more serious issue that I learned (or rather forgotten about before
> > and remembered now) is the whole DVCSes keep the whole repository
> > history locally aspect, which has important ramifications. If the
> > repository is big, although disk space may not be much of an issue,
> 
> I still find myself worrying about disk usage, despite being able to get a
> 2T drive these days for under a hundred bucks. Old patterns of thought die
> hard.

And some things will likely _always_ make disk usage a concern. Video would be 
a 
good example. If you have much video, even with good compression, it's going to 
take up a lot of space. Granted, there are _lots_ of use cases which just don't 
take up enough disk space to matter anymore, but you can _always_ find ways to 
use up disk space. Entertainingly, a fellow I know had a friend who joked that 
he could always hold all of his data in a shoebox. Originally, it was punch 
cards. Then it  was 5 1/4" floppy disks. Then it was 3 1/2" floppy disks. Then 
it 
was CDs. Etc. Storage devices keep getting bigger and bigger, but we keep 
finding 
ways to fill them...

- Jonathan M Davis

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Brad Roberts]

On Tue, 1 Feb 2011, Walter Bright wrote:

> Bruno Medeiros wrote:
> > A more serious issue that I learned (or rather forgotten about before and
> > remembered now) is the whole DVCSes keep the whole repository history
> > locally aspect, which has important ramifications. If the repository is big,
> > although disk space may not be much of an issue,
> 
> I still find myself worrying about disk usage, despite being able to get a 2T
> drive these days for under a hundred bucks. Old patterns of thought die hard.

For what it's worth, the sizes of the key git dirs on my box:

dmd.git == 4.4 - 5.9M (depends on if the gc has run recently to re-pack 
new objects)

druntime.git == 1.4 - 3.0M

phobos.git == 5.1 - 6.7M

The checked out copy of each of those is considerably more than the packed 
full history.  The size, inclusive of full history and the checked out 
copy, after a make clean:

dmd   15M
druntime   4M
phobos16M

Ie, essentially negligable.

Later,
Brad

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Brad Roberts wrote:

Ie, essentially negligable.


Yeah, and I caught myself worrying about the disk usage from having two clones 
of the git repository (one for D1, the other for D2).

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Andrej Mitrovic]

Bleh. I tried to use Git to update some of the doc files, but getting
the thing to work will be a miracle.

git can't find the public keys unless I use msysgit. Great. How
exactly do I cd to D:\ ?

So I try git-gui. Seems to work fine, I clone the forked repo and make
a few changes. I try to commit, it says I have to update first. So I
do that. *Error: crash crash crash*. I try to close the thing, it just
keeps crashing. CTRL+ALT+DEL time..

Okay, I try another GUI package, GitExtensions. I make new
public/private keys and add it to github, I'm about to clone but then
I get this "fatal: The remote end hung up unexpectedly".

I don't know what to say..

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Brad Roberts]

On 2/1/2011 6:17 PM, Andrej Mitrovic wrote:
> Bleh. I tried to use Git to update some of the doc files, but getting
> the thing to work will be a miracle.
> 
> git can't find the public keys unless I use msysgit. Great. How
> exactly do I cd to D:\ ?
> 
> So I try git-gui. Seems to work fine, I clone the forked repo and make
> a few changes. I try to commit, it says I have to update first. So I
> do that. *Error: crash crash crash*. I try to close the thing, it just
> keeps crashing. CTRL+ALT+DEL time..
> 
> Okay, I try another GUI package, GitExtensions. I make new
> public/private keys and add it to github, I'm about to clone but then
> I get this "fatal: The remote end hung up unexpectedly".
> 
> I don't know what to say..

I use cygwin for all my windows work (which I try to keep to a minimum).  Works 
just fine in that environment.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Andrej Mitrovic wrote:

I don't know what to say..


Git is a Linux program and will never work right on Windows. The problems you're 
experiencing are classic ones I find whenever I attempt to use a Linux program 
that has been "ported" to Windows.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Andrej Mitrovic]

On 2/2/11, Walter Bright  wrote:
> Andrej Mitrovic wrote:
>> I don't know what to say..
>
> Git is a Linux program and will never work right on Windows. The problems
> you're
> experiencing are classic ones I find whenever I attempt to use a Linux
> program
> that has been "ported" to Windows.
>

Yeah, I know what you mean. "Use my app on Windows too, it works! But
you have to install this Linux simulator first, though".

Is this why you've made your own version of make and microemacs for
Windows? I honestly can't blame you. :)

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Brad Roberts]

On 2/1/2011 7:55 PM, Andrej Mitrovic wrote:
> On 2/2/11, Walter Bright  wrote:
>> Andrej Mitrovic wrote:
>>> I don't know what to say..
>>
>> Git is a Linux program and will never work right on Windows. The problems
>> you're
>> experiencing are classic ones I find whenever I attempt to use a Linux
>> program
>> that has been "ported" to Windows.
>>
> 
> Yeah, I know what you mean. "Use my app on Windows too, it works! But
> you have to install this Linux simulator first, though".
> 
> Is this why you've made your own version of make and microemacs for
> Windows? I honestly can't blame you. :)

Of course, it forms a nice vicious circle.  Without users, there's little 
incentive to fix and chances are there's fewer
users reporting bugs.

Sounds.. familiar. :)

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Andrej Mitrovic]

On 2/2/11, Walter Bright  wrote:
>

I've noticed you have "Version Control with Git" listed in your list
of books. Did you just buy that recently, or were you secretly
planning to switch to Git at the instant someone mentioned it? :p

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Andrej Mitrovic wrote:

Is this why you've made your own version of make and microemacs for
Windows? I honestly can't blame you. :)


Microemacs floated around the intarnets for free back in the 80's, and I liked 
it because it was very small, fast, and customizable. Having an editor that fit 
in 50k was just the ticket for a floppy based system. Most code editors of the 
day were many times larger, took forever to load, etc.


I wrote my own make because I needed one to sell and so couldn't use someone 
else's.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Andrej Mitrovic]

On 2/2/11, Andrej Mitrovic  wrote:
> On 2/2/11, Walter Bright  wrote:
>>
>
> ...listed in your list...
>

Crap.. I just made a 2-dimensional book list by accident. My bad.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Andrej Mitrovic wrote:

I've noticed you have "Version Control with Git" listed in your list
of books. Did you just buy that recently, or were you secretly
planning to switch to Git at the instant someone mentioned it? :p


I listed it recently.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[David Nadlinger]

On 2/2/11 3:17 AM, Andrej Mitrovic wrote:

Bleh. I tried to use Git to update some of the doc files, but getting
the thing to work will be a miracle.

git can't find the public keys unless I use msysgit. Great. How
exactly do I cd to D:\ ?


If you are new to Git or SSH, the folks at GitHub have put up a tutorial 
explaining how to generate and set up a pair of SSH keys: 
http://help.github.com/msysgit-key-setup/. There is also a page 
describing solutions to some SSH setup problems: 
http://help.github.com/troubleshooting-ssh/.


If you already have a private/public key and want to use it with Git, 
either copy them to Git's .ssh/ directory or edit the .ssh/config of the 
SSH instance used by Git accordingly. If you need to refer to 
»D:\somefile« inside the MSYS shell, use »/d/somefile«.


I don't quite get what you mean with »git can't find the public keys 
unless I use msysgit«. Obviously, you need to modify the configuration 
of the SSH program Git uses, but other than that, you don't need to use 
the MSYS shell for setting up stuff – you can just use Windows Explorer 
and your favorite text editor for that as well.


David

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Jérôme M. Berger]

Andrej Mitrovic wrote:
> Bleh. I tried to use Git to update some of the doc files, but getting
> the thing to work will be a miracle.
> 
> git can't find the public keys unless I use msysgit. Great. How
> exactly do I cd to D:\ ?
> 
> So I try git-gui. Seems to work fine, I clone the forked repo and make
> a few changes. I try to commit, it says I have to update first. So I
> do that. *Error: crash crash crash*. I try to close the thing, it just
> keeps crashing. CTRL+ALT+DEL time..
> 
> Okay, I try another GUI package, GitExtensions. I make new
> public/private keys and add it to github, I'm about to clone but then
> I get this "fatal: The remote end hung up unexpectedly".
> 
> I don't know what to say..

Why do you think I keep arguing against Git every chance I get?

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 01/02/2011 23:07, Walter Bright wrote:

Bruno Medeiros wrote:

A more serious issue that I learned (or rather forgotten about before
and remembered now) is the whole DVCSes keep the whole repository
history locally aspect, which has important ramifications. If the
repository is big, although disk space may not be much of an issue,


I still find myself worrying about disk usage, despite being able to get
a 2T drive these days for under a hundred bucks. Old patterns of thought
die hard.


Well, like I said, my concern about size is not so much disk space, but 
the time to make local copies of the repository, or cloning it from the 
internet (and the associated transfer times), both of which are not 
neglectable yet.
My project at work could easily have gone to 1Gb of repo size if in the 
last year or so it has been stored on a DVCS! :S


I hope this gets addressed at some point. But I fear that the main 
developers of both Git and Mercurial may be too "biased" to experience 
projects which are typically somewhat small in size, in terms of bytes 
(projects that consist almost entirely of source code).
For example, in UI applications it would be common to store binary data 
(images, sounds, etc.) in the source control. The other case is what I 
mentioned before, wanting to store dependencies together with the 
project (in my case including the javadoc and source code of the 
dependencies - and there's very good reasons to want to do that).


In this analysis:
http://code.google.com/p/support/wiki/DVCSAnalysis
they said that Git has some functionality to address this issue:
"Client Storage Management. Both Mercurial and Git allow users to 
selectively pull branches from other repositories. This provides an 
upfront mechanism for narrowing the amount of history stored locally. In 
addition, Git allows previously pulled branches to be discarded. Git 
also allows old revision data to be pruned from the local repository 
(while still keeping recent revision data on those branches). With 
Mercurial, if a branch is in the local repository, then all of its 
revisions (back to the very initial commit) must also be present, and 
there is no way to prune branches other than by creating a new 
repository and selectively pulling branches into it. There has been some 
work addressing this in Mercurial, but nothing official yet."


However I couldn't find more info about this, and other articles and 
comments about Git seem to omit or contradict this... :S

Can Git really have an usable but incomplete local clone?

--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-02-04 11:12:12 -0500, Bruno Medeiros 
 said:



Can Git really have an usable but incomplete local clone?


Yes, it's called a shallow clone. See the --depth switch of git clone:



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Ulrik Mikaelsson]

2011/2/4 Bruno Medeiros :
>
> Well, like I said, my concern about size is not so much disk space, but the
> time to make local copies of the repository, or cloning it from the internet
> (and the associated transfer times), both of which are not neglectable yet.
> My project at work could easily have gone to 1Gb of repo size if in the last
> year or so it has been stored on a DVCS! :S
>
> I hope this gets addressed at some point. But I fear that the main
> developers of both Git and Mercurial may be too "biased" to experience
> projects which are typically somewhat small in size, in terms of bytes
> (projects that consist almost entirely of source code).
> For example, in UI applications it would be common to store binary data
> (images, sounds, etc.) in the source control. The other case is what I
> mentioned before, wanting to store dependencies together with the project
> (in my case including the javadoc and source code of the dependencies - and
> there's very good reasons to want to do that).

I think the storage/bandwidth requirements of DVCS:s are very often
exagerated, especially for text, but also somewhat for blobs.
 * For text-content, the compression of archives reduces them to,
perhaps, 1/5 of their original size?
   - That means, that unless you completely rewrite a file 5 times
during the course of a project, simple per-revision-compression of the
file will turn out smaller, than the single uncompressed base-file
that subversion transfers and stores.
   - The delta-compression applied ensures small changes does not
count as a "rewrite".
 * For blobs, the archive-compression may not do as much, and they
certainly pose a larger challenge for storing history, but:
   - AFAIU, at least git delta-compresses even binaries so even
changes in them might be slightly reduced (dunno about the others)
   - I think more and more graphics are today are written in SVG?
   - I believe, for most projects, audio-files are usually not changed
very often, once entered a project? Usually existing samples are
simply copied in?
 * For both binaries and text, and for most projects, the latest
revision is usually the largest. (Projects usually grow over time,
they don't consistently shrink) I.E. older revisions are, compared to
current, much much smaller, making the size of old history smaller
compared to the size of current history.

Finally, as a test, I tried checking out the last version of druntime
from SVN and compare it to git (AFICT, history were preserved in the
git-migration), the results were about what I expected. Checking out
trunk from SVN, and the whole history from git:
  SVN: 7.06 seconds, 5,3 MB on disk
  Git: 2.88 seconds, 3.5 MB on disk
  Improvement Git/SVN: time reduced by 59%, space reduced by 34%.

I did not measure bandwidth, but my guess is it is somewhere between
the disk- and time- reductions. Also, if someone has an example of a
recently converted repository including some blobs it would make an
interesting experiment to repeat.

Regards
/ Ulrik

-

ulrik@ulrik ~/p/test> time svn co
http://svn.dsource.org/projects/druntime/trunk druntime_svn
...
0.26user 0.21system 0:07.06elapsed 6%CPU (0avgtext+0avgdata 47808maxresident)k
544inputs+11736outputs (3major+3275minor)pagefaults 0swaps
ulrik@ulrik ~/p/test> du -sh druntime_svn
5,3Mdruntime_svn

ulrik@ulrik ~/p/test> time git clone
git://github.com/D-Programming-Language/druntime.git druntime_git
...
0.26user 0.06system 0:02.88elapsed 11%CPU (0avgtext+0avgdata 14320maxresident)k
3704inputs+7168outputs (18major+1822minor)pagefaults 0swaps
ulrik@ulrik ~/p/test> du -sh druntime_git/
3,5Mdruntime_git/

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 06/02/2011 14:17, Ulrik Mikaelsson wrote:

2011/2/4 Bruno Medeiros:


Well, like I said, my concern about size is not so much disk space, but the
time to make local copies of the repository, or cloning it from the internet
(and the associated transfer times), both of which are not neglectable yet.
My project at work could easily have gone to 1Gb of repo size if in the last
year or so it has been stored on a DVCS! :S

I hope this gets addressed at some point. But I fear that the main
developers of both Git and Mercurial may be too "biased" to experience
projects which are typically somewhat small in size, in terms of bytes
(projects that consist almost entirely of source code).
For example, in UI applications it would be common to store binary data
(images, sounds, etc.) in the source control. The other case is what I
mentioned before, wanting to store dependencies together with the project
(in my case including the javadoc and source code of the dependencies - and
there's very good reasons to want to do that).


I think the storage/bandwidth requirements of DVCS:s are very often
exagerated, especially for text, but also somewhat for blobs.
  * For text-content, the compression of archives reduces them to,
perhaps, 1/5 of their original size?
- That means, that unless you completely rewrite a file 5 times
during the course of a project, simple per-revision-compression of the
file will turn out smaller, than the single uncompressed base-file
that subversion transfers and stores.
- The delta-compression applied ensures small changes does not
count as a "rewrite".
  * For blobs, the archive-compression may not do as much, and they
certainly pose a larger challenge for storing history, but:
- AFAIU, at least git delta-compresses even binaries so even
changes in them might be slightly reduced (dunno about the others)
- I think more and more graphics are today are written in SVG?
- I believe, for most projects, audio-files are usually not changed
very often, once entered a project? Usually existing samples are
simply copied in?
  * For both binaries and text, and for most projects, the latest
revision is usually the largest. (Projects usually grow over time,
they don't consistently shrink) I.E. older revisions are, compared to
current, much much smaller, making the size of old history smaller
compared to the size of current history.

Finally, as a test, I tried checking out the last version of druntime
from SVN and compare it to git (AFICT, history were preserved in the
git-migration), the results were about what I expected. Checking out
trunk from SVN, and the whole history from git:
   SVN: 7.06 seconds, 5,3 MB on disk
   Git: 2.88 seconds, 3.5 MB on disk
   Improvement Git/SVN: time reduced by 59%, space reduced by 34%.

I did not measure bandwidth, but my guess is it is somewhere between
the disk- and time- reductions. Also, if someone has an example of a
recently converted repository including some blobs it would make an
interesting experiment to repeat.

Regards
/ Ulrik

-

ulrik@ulrik ~/p/test>  time svn co
http://svn.dsource.org/projects/druntime/trunk druntime_svn
...
0.26user 0.21system 0:07.06elapsed 6%CPU (0avgtext+0avgdata 47808maxresident)k
544inputs+11736outputs (3major+3275minor)pagefaults 0swaps
ulrik@ulrik ~/p/test>  du -sh druntime_svn
5,3Mdruntime_svn

ulrik@ulrik ~/p/test>  time git clone
git://github.com/D-Programming-Language/druntime.git druntime_git
...
0.26user 0.06system 0:02.88elapsed 11%CPU (0avgtext+0avgdata 14320maxresident)k
3704inputs+7168outputs (18major+1822minor)pagefaults 0swaps
ulrik@ulrik ~/p/test>  du -sh druntime_git/
3,5Mdruntime_git/



Yes, Brad had posted some statistics of the size of the Git repositories 
for dmd, druntime, and phobos, and yes, they are pretty small.
Projects which contains practically only source code, and little to no 
binary data are unlikely to grow much and repo size ever be a problem. 
But it might not be the case for other projects (also considering that 
binary data is usually already well compressed, like .zip, .jpg, .mp3, 
.ogg, etc., so VCS compression won't help much).


It's unlikely you will see converted repositories with a lot of changing 
blob data. DVCS, at the least in the way they work currently, simply 
kill this workflow/organization-pattern.
I very much suspect this issue will become more important as time goes 
on - a lot of people are still new to DVCS and they still don't realize 
the full implications of that architecture with regards to repo size. 
Any file you commit will add to the repository size *FOREVER*. I'm 
pretty sure we haven't heard the last word on the VCS battle, in that in 
a few years time people are *again* talking about and switching to 
another VCS :( . Mark these words. (The only way this is not going to 
happen is if Git or Mercurial are able to address this issue in a 
satisfactory way, which I'm not sure is possible or easy)



--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 04/02/2011 20:11, Michel Fortin wrote:

On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 said:


Can Git really have an usable but incomplete local clone?


Yes, it's called a shallow clone. See the --depth switch of git clone:





I was about to say "Cool!", but then I checked the doc on that link and 
it says:
"A shallow repository has a number of limitations (you cannot clone or 
fetch from it, nor push from nor into it), but is adequate if you are 
only interested in the recent history of a large project with a long 
history, and would want to send in fixes as patches. "
So it's actually not good for what I meant, since it is barely usable 
(you cannot push from it). :(



--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-02-09 07:49:31 -0500, Bruno Medeiros 
 said:



On 04/02/2011 20:11, Michel Fortin wrote:

On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 said:


Can Git really have an usable but incomplete local clone?


Yes, it's called a shallow clone. See the --depth switch of git clone:



I was about to say "Cool!", but then I checked the doc on that link and 
it says:
"A shallow repository has a number of limitations (you cannot clone or 
fetch from it, nor push from nor into it), but is adequate if you are 
only interested in the recent history of a large project with a long 
history, and would want to send in fixes as patches. "
So it's actually not good for what I meant, since it is barely usable 
(you cannot push from it). :(


Actually, pushing from a shallow repository can work, but if your 
history is not deep enough it will be a problem when git tries 
determine the common ancestor. Be sure to have enough depth so that 
your history contains the common ancestor of all the branches you might 
want to merge, and also make sure the remote repository won't rewrite 
history beyond that point and you should be safe. At least, that's what 
I understand from:



--


Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Jérôme M. Berger]

Bruno Medeiros wrote:
> Yes, Brad had posted some statistics of the size of the Git repositories
> for dmd, druntime, and phobos, and yes, they are pretty small.
> Projects which contains practically only source code, and little to no
> binary data are unlikely to grow much and repo size ever be a problem.
> But it might not be the case for other projects (also considering that
> binary data is usually already well compressed, like .zip, .jpg, .mp3,
> .ogg, etc., so VCS compression won't help much).
> 
> It's unlikely you will see converted repositories with a lot of changing
> blob data. DVCS, at the least in the way they work currently, simply
> kill this workflow/organization-pattern.
> I very much suspect this issue will become more important as time goes
> on - a lot of people are still new to DVCS and they still don't realize
> the full implications of that architecture with regards to repo size.
> Any file you commit will add to the repository size *FOREVER*. I'm
> pretty sure we haven't heard the last word on the VCS battle, in that in
> a few years time people are *again* talking about and switching to
> another VCS :( . Mark these words. (The only way this is not going to
> happen is if Git or Mercurial are able to address this issue in a
> satisfactory way, which I'm not sure is possible or easy)
> 
There are several Mercurial extensions that attempt to address this
issue. See for example: http://wiki.netbeans.org/HgExternalBinaries
or http://mercurial.selenic.com/wiki/BigfilesExtension

I do not know how well they perform in practice.

Jerome
-- 
mailto:jeber...@free.fr
http://jeberger.free.fr
Jabber: jeber...@jabber.fr



signature.asc
Description: OpenPGP digital signature

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Ulrik Mikaelsson]

2011/2/9 Bruno Medeiros :
>
> It's unlikely you will see converted repositories with a lot of changing
> blob data. DVCS, at the least in the way they work currently, simply kill
> this workflow/organization-pattern.
> I very much suspect this issue will become more important as time goes on -
> a lot of people are still new to DVCS and they still don't realize the full
> implications of that architecture with regards to repo size. Any file you
> commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
> heard the last word on the VCS battle, in that in a few years time people
> are *again* talking about and switching to another VCS :( . Mark these
> words. (The only way this is not going to happen is if Git or Mercurial are
> able to address this issue in a satisfactory way, which I'm not sure is
> possible or easy)
>

You don't happen to know about any projects of this kind in any other
VCS that can be practically tested, do you?

Besides, AFAIU this discussion was originally regarding to the D
language components, I.E. DMD, druntime and Phobos. Not a lot of
binaries here.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[nedbrek]

Hello all,

"Michel Fortin"  wrote in message 
news:iiu8dm$10te$1...@digitalmars.com...
> On 2011-02-09 07:49:31 -0500, Bruno Medeiros 
>  said:
>> On 04/02/2011 20:11, Michel Fortin wrote:
>>> On 2011-02-04 11:12:12 -0500, Bruno Medeiros
>>>  said:
>>>
 Can Git really have an usable but incomplete local clone?
>>>
>>> Yes, it's called a shallow clone. See the --depth switch of git clone:
>>> 
>>
>> I was about to say "Cool!", but then I checked the doc on that link and 
>> it says:
>> "A shallow repository has a number of limitations (you cannot clone or 
>> fetch from it, nor push from nor into it), but is adequate if you are 
>> only interested in the recent history of a large project with a long 
>> history, and would want to send in fixes as patches. "
>> So it's actually not good for what I meant, since it is barely usable 
>> (you cannot push from it). :(
>
> Actually, pushing from a shallow repository can work, but if your history 
> is not deep enough it will be a problem when git tries determine the 
> common ancestor. Be sure to have enough depth so that your history 
> contains the common ancestor of all the branches you might want to merge, 
> and also make sure the remote repository won't rewrite history beyond that 
> point and you should be safe. At least, that's what

The other way to collaborate is to email someone a diff.  Git has a lot of 
support for extracting diffs from emails and applying the patches.

HTH,
Ned

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 09/02/2011 23:02, Ulrik Mikaelsson wrote:

2011/2/9 Bruno Medeiros:


It's unlikely you will see converted repositories with a lot of changing
blob data. DVCS, at the least in the way they work currently, simply kill
this workflow/organization-pattern.
I very much suspect this issue will become more important as time goes on -
a lot of people are still new to DVCS and they still don't realize the full
implications of that architecture with regards to repo size. Any file you
commit will add to the repository size *FOREVER*. I'm pretty sure we haven't
heard the last word on the VCS battle, in that in a few years time people
are *again* talking about and switching to another VCS :( . Mark these
words. (The only way this is not going to happen is if Git or Mercurial are
able to address this issue in a satisfactory way, which I'm not sure is
possible or easy)



You don't happen to know about any projects of this kind in any other
VCS that can be practically tested, do you?



You mean a project like that, hosted in Subversion or CVS (so that you 
can convert it to Git/Mercurial and see how it is in terms of repo size)?
I don't know any of the top of my head, except the one in my job, but 
naturally it is commercial and closed-source so I can't share it.
I'm cloning the Mozilla Firefox repo right now, I'm curious how big it 
is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29)


But other than that, what exactly do you want to test? There is no 
specific thing to test, if you add a binary file (from a format that is 
already compressed, like zip, jar, jpg, etc.) of size X, you will 
increase the repo size by X bytes forever. There is no other way around 
it. (Unless on Git you rewrite the history on the repo, which doubtfully 
will ever be allowed on central repositories)


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 09/02/2011 14:27, Michel Fortin wrote:

On 2011-02-09 07:49:31 -0500, Bruno Medeiros
 said:


On 04/02/2011 20:11, Michel Fortin wrote:

On 2011-02-04 11:12:12 -0500, Bruno Medeiros
 said:


Can Git really have an usable but incomplete local clone?


Yes, it's called a shallow clone. See the --depth switch of git clone:



I was about to say "Cool!", but then I checked the doc on that link
and it says:
"A shallow repository has a number of limitations (you cannot clone or
fetch from it, nor push from nor into it), but is adequate if you are
only interested in the recent history of a large project with a long
history, and would want to send in fixes as patches. "
So it's actually not good for what I meant, since it is barely usable
(you cannot push from it). :(


Actually, pushing from a shallow repository can work, but if your
history is not deep enough it will be a problem when git tries determine
the common ancestor. Be sure to have enough depth so that your history
contains the common ancestor of all the branches you might want to
merge, and also make sure the remote repository won't rewrite history
beyond that point and you should be safe. At least, that's what I
understand from:





Interesting. But it still feels very much like a second-class 
functionality, not something they really have in mind to support well, 
at least not yet.


Ideally, if one wants to do push but the ancestor history is incomplete, 
the VCS would download from the central repository whatever 
revision/changeset information was missing.


Before someone says, oh but that defeats some of the purposes of a 
distributed VCS, like being able to work offline. I know, and I 
personally don't care that much, in fact I find this "benefit" of DVCS 
has been overvalued way out of proportion. Does anyone do any serious 
coding while being offline for an extended period of time? Some people 
mentioned coding on the move, with laptops, but seriously, even if I am 
connected to the Internet I cannot code with my laptop only, I need it 
connected to a monitor, as well as a mouse, (and preferably a keyboard 
as well).


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Jean Crystof]

Bruno Medeiros Wrote:

> On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
> > 2011/2/9 Bruno Medeiros:
> >>
> >> It's unlikely you will see converted repositories with a lot of changing
> >> blob data. DVCS, at the least in the way they work currently, simply kill
> >> this workflow/organization-pattern.
> >> I very much suspect this issue will become more important as time goes on -
> >> a lot of people are still new to DVCS and they still don't realize the full
> >> implications of that architecture with regards to repo size. Any file you
> >> commit will add to the repository size *FOREVER*. I'm pretty sure we 
> >> haven't
> >> heard the last word on the VCS battle, in that in a few years time people
> >> are *again* talking about and switching to another VCS :( . Mark these
> >> words. (The only way this is not going to happen is if Git or Mercurial are
> >> able to address this issue in a satisfactory way, which I'm not sure is
> >> possible or easy)
> >>
> >
> > You don't happen to know about any projects of this kind in any other
> > VCS that can be practically tested, do you?
> >
> 
> You mean a project like that, hosted in Subversion or CVS (so that you 
> can convert it to Git/Mercurial and see how it is in terms of repo size)?
> I don't know any of the top of my head, except the one in my job, but 
> naturally it is commercial and closed-source so I can't share it.
> I'm cloning the Mozilla Firefox repo right now, I'm curious how big it 
> is. ( https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29)
> 
> But other than that, what exactly do you want to test? There is no 
> specific thing to test, if you add a binary file (from a format that is 
> already compressed, like zip, jar, jpg, etc.) of size X, you will 
> increase the repo size by X bytes forever. There is no other way around 
> it. (Unless on Git you rewrite the history on the repo, which doubtfully 
> will ever be allowed on central repositories)

One thing we've done at work with game asset files is we put them in a separate 
repository and to conserve space we use a cleaned branch as a base for work 
repository. The "graph" below shows how it works

initial state -> alpha1 -> alpha2 -> beta1 -> internal rev X -> internal rev 
X+1 -> internal rev X+2 -> ... -> internal rev X+n -> beta2

Now we have a new beta2. What happens next is we take a snapshot copy of the 
state of beta2, go back to beta1, create a new branch and "paste" the snapshot 
there. Now we move the old working branch with internal revisions to someplace 
safe and start using this as a base. And the work continues with this:

initial state -> alpha1 -> alpha2 -> beta1 -> beta2 > internal rev X+n+1 -> ...

The repository size won't become a problem with text / source code.

Since you're a SVN advocate, please explain how well it works with 2500 GB of 
asset files?

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Michel Fortin]

On 2011-02-11 08:05:27 -0500, Bruno Medeiros 
 said:



On 09/02/2011 14:27, Michel Fortin wrote:

On 2011-02-09 07:49:31 -0500, Bruno Medeiros
 said:


I was about to say "Cool!", but then I checked the doc on that link
and it says:
"A shallow repository has a number of limitations (you cannot clone or
fetch from it, nor push from nor into it), but is adequate if you are
only interested in the recent history of a large project with a long
history, and would want to send in fixes as patches. "
So it's actually not good for what I meant, since it is barely usable
(you cannot push from it). :(


Actually, pushing from a shallow repository can work, but if your
history is not deep enough it will be a problem when git tries determine
the common ancestor. Be sure to have enough depth so that your history
contains the common ancestor of all the branches you might want to
merge, and also make sure the remote repository won't rewrite history
beyond that point and you should be safe. At least, that's what I
understand from:



Interesting. 


But it still feels very much like a second-class functionality, not 
something they really have in mind to support well, at least not yet.


Ideally, if one wants to do push but the ancestor history is 
incomplete, the VCS would download from the central repository whatever 
revision/changeset information was missing.


Actually, there's no "central" repository in Git. But I agree with your 
idea in general: one of the remotes could be designated as being a 
source to look for when encountering a missing object, probably the one 
from which you shallowly cloned from. All we need is someone to 
implement that.



--
Michel Fortin
michel.for...@michelf.com
http://michelf.com/

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Walter Bright]

Bruno Medeiros wrote:
but seriously, even if I am 
connected to the Internet I cannot code with my laptop only, I need it 
connected to a monitor, as well as a mouse, (and preferably a keyboard 
as well).


I found I can't code on my laptop anymore; I am too used to and needful of a 
large screen.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Ulrik Mikaelsson]

2011/2/11 Bruno Medeiros :
> On 09/02/2011 23:02, Ulrik Mikaelsson wrote:
>> You don't happen to know about any projects of this kind in any other
>> VCS that can be practically tested, do you?
>>
>
> You mean a project like that, hosted in Subversion or CVS (so that you can
> convert it to Git/Mercurial and see how it is in terms of repo size)?
> I don't know any of the top of my head, except the one in my job, but
> naturally it is commercial and closed-source so I can't share it.
> I'm cloning the Mozilla Firefox repo right now, I'm curious how big it is. (
> https://developer.mozilla.org/en/Mozilla_Source_Code_%28Mercurial%29)
>
> But other than that, what exactly do you want to test? There is no specific
> thing to test, if you add a binary file (from a format that is already
> compressed, like zip, jar, jpg, etc.) of size X, you will increase the repo
> size by X bytes forever. There is no other way around it. (Unless on Git you
> rewrite the history on the repo, which doubtfully will ever be allowed on
> central repositories)
>

I want to test how much overhead the git-version _actually_ is,
compared to the SVN-version. Even though the jpg are unlikely to be
much more compressible with regular compression, with
delta-compression and the fact of growing project-size it might still
be interesting to see how much overhead we're talking, and what the
performance over network is.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 11/02/2011 23:30, Walter Bright wrote:

Bruno Medeiros wrote:

but seriously, even if I am connected to the Internet I cannot code
with my laptop only, I need it connected to a monitor, as well as a
mouse, (and preferably a keyboard as well).


I found I can't code on my laptop anymore; I am too used to and needful
of a large screen.



Yeah, that was my point as well. The laptop monitor is too small for 
coding, (unless one has a huge laptop).


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 11/02/2011 18:31, Michel Fortin wrote:


Ideally, if one wants to do push but the ancestor history is
incomplete, the VCS would download from the central repository
whatever revision/changeset information was missing.


Actually, there's no "central" repository in Git.


That stuff about DVCS not having a central repository is another thing 
that is being said a lot, but is only true in a very shallow (and 
non-useful) way. Yes, in DVCS there are no more "working copies" as in 
Subversion, now everyone's working copy is a full fledged 
repository/clone that in technical terms is peer of any other repository.
However, from an organizational point of view in a project, there is 
always going to be a "central" repository. The one that actually 
represents the product/application/library, where the builds and 
releases are made from. (Of course, there could be more than one central 
repository if there are multiple kinds of releases like 
stable/experimental, or forks of the the product, etc.)
Maybe the DVCS world likes the term public/shared repository better, but 
that doesn't make much difference.



--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 11/02/2011 13:14, Jean Crystof wrote:


Since you're a SVN advocate, please explain how well it works with 2500 GB of 
asset files?


I'm not an SVN advocate.
I have started using DVCSs over Subversion, and generally I agree they 
are better, but what I'm saying is that they are not all roses... it is 
not a complete win-win, there are a few important cons, like this one.


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Russel Winder]

On Wed, 2011-02-16 at 14:51 +, Bruno Medeiros wrote:
[ . . . ]
> That stuff about DVCS not having a central repository is another thing 
> that is being said a lot, but is only true in a very shallow (and 
> non-useful) way. Yes, in DVCS there are no more "working copies" as in 
> Subversion, now everyone's working copy is a full fledged 
> repository/clone that in technical terms is peer of any other repository.
> However, from an organizational point of view in a project, there is 
> always going to be a "central" repository. The one that actually 
> represents the product/application/library, where the builds and 
> releases are made from. (Of course, there could be more than one central 
> repository if there are multiple kinds of releases like 
> stable/experimental, or forks of the the product, etc.)

Definitely the case.  There can only be one repository that represents
the official state of a given project.  That isn't really the issue in
the move from CVCS systems to DVCS systems.

> Maybe the DVCS world likes the term public/shared repository better, but 
> that doesn't make much difference.

In the Bazaar community, and I think increasingly in Mercurial and Git
ones, people talk of the "mainline" or "master". 

-- 
Russel.
=
Dr Russel Winder  t: +44 20 7585 2200   voip: sip:russel.win...@ekiga.net
41 Buckmaster Roadm: +44 7770 465 077   xmpp: rus...@russel.org.uk
London SW11 1EN, UK   w: www.russel.org.uk  skype: russel_winder


signature.asc
Description: This is a digitally signed message part

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Ulrik Mikaelsson]

2011/2/16 Russel Winder :
>
> Definitely the case.  There can only be one repository that represents
> the official state of a given project.  That isn't really the issue in
> the move from CVCS systems to DVCS systems.
>
Just note that not all projects have a specific "state" to represent.
Many projects are centered around the concept of a centralized
project, a "core"-team, and all-around central organisation and
planning. Some projects however, I guess the Linux kernel is a prime
example, have been quite de-centralized even in their nature for a
long time.

In the case of KDE, for a centralized example, there is a definite
"project version", which is the version currently blessed by the
central project team. There is a centralized project planning,
including meetings, setting out goals for the coming development.

In the case of Linux, it's FAR less obvious. Sure, most people see
master@torvalds/linux-2.6.git as THE Linux-version. However, there are
many other trees interesting to track as well, such as the various
distribution-trees which might incorporate many drivers not in
mainline, especially for older stability-oriented kernels, RHEL or
Debian is probably THE version to care about. You might also be
interested in special-environment-kernels, such as non x86-kernels, in
which case you're probably more interested in the central repo for
that architecture, which is rarely Linuses. Also, IIRC, hard and soft
realtime-enthusiasts neither looks at linuses tree first.

Above all, in the Linux-kernel, there is not much of "centralised
planning". Linus doesn't call to a big planning-meeting quarterly to
set up specific milestones for the next kernel release, but in the
beginning of each cycle, he is spammed with things already developed
independently, scratching someones itch. He then cherry-picks the
things that has got good reviews and are interesting for where he
wants to go with the kernel. That is not to say that there aren't a
lot of coordination and communication, but there isn't a clear
centralized authority steering development in the same ways as in many
other projects.

The bottom line is, many projects, even ones using DVCS, are often
centrally organized. However, the Linux kernel is clear evidence it is
not the only project model that works.

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Bruno Medeiros]

On 16/02/2011 17:54, Ulrik Mikaelsson wrote:

2011/2/16 Russel Winder:


Definitely the case.  There can only be one repository that represents
the official state of a given project.  That isn't really the issue in
the move from CVCS systems to DVCS systems.


Just note that not all projects have a specific "state" to represent.
Many projects are centered around the concept of a centralized
project, a "core"-team, and all-around central organisation and
planning. Some projects however, I guess the Linux kernel is a prime
example, have been quite de-centralized even in their nature for a
long time.

In the case of KDE, for a centralized example, there is a definite
"project version", which is the version currently blessed by the
central project team. There is a centralized project planning,
including meetings, setting out goals for the coming development.

In the case of Linux, it's FAR less obvious. Sure, most people see
master@torvalds/linux-2.6.git as THE Linux-version. However, there are
many other trees interesting to track as well, such as the various
distribution-trees which might incorporate many drivers not in
mainline, especially for older stability-oriented kernels, RHEL or
Debian is probably THE version to care about. You might also be
interested in special-environment-kernels, such as non x86-kernels, in
which case you're probably more interested in the central repo for
that architecture, which is rarely Linuses. Also, IIRC, hard and soft
realtime-enthusiasts neither looks at linuses tree first.

Above all, in the Linux-kernel, there is not much of "centralised
planning". Linus doesn't call to a big planning-meeting quarterly to
set up specific milestones for the next kernel release, but in the
beginning of each cycle, he is spammed with things already developed
independently, scratching someones itch. He then cherry-picks the
things that has got good reviews and are interesting for where he
wants to go with the kernel. That is not to say that there aren't a
lot of coordination and communication, but there isn't a clear
centralized authority steering development in the same ways as in many
other projects.

The bottom line is, many projects, even ones using DVCS, are often
centrally organized. However, the Linux kernel is clear evidence it is
not the only project model that works.


Yeah, that's true. Some projects, the Linux kernel being one of the best 
examples, are more distributed in nature than not, in actual 
organizational terms. But projects like that are (and will remain) in 
the minority, a minority which is probably a very, very small.


--
Bruno Medeiros - Software Engineer

Re: DVCS vs. Subversion brittleness (was Re: Moving to D)

[Ulrik Mikaelsson]

2011/2/17 Bruno Medeiros :
>
> Yeah, that's true. Some projects, the Linux kernel being one of the best
> examples, are more distributed in nature than not, in actual organizational
> terms. But projects like that are (and will remain) in the minority, a
> minority which is probably a very, very small.
>
Indeed. However, I think it will be interesting to see how things
develop, if this will be the case in the future too. The Linux kernel,
and a few other projects were probably decentralized from start by
necessity, filling very different purposes. However, new tools tends
to affect models, which might make it a bit more common in the future.
In any case, it's an interesting time to do software development.