Spolsky's last (it says here) opinion piece

http://www.joelonsoftware.com/items/2010/03/17.html is about version 
control. If you use VC software, it might be worth reading.

Jerry
-- 
Discovery consists of seeing what everybody has seen, and thinking what
nobody has thought.    .. Albert Szent-Gyorgi
�����������������������������������������������������������������������

>http://www.joelonsoftware.com/items/2010/03/17.html is about version 
>control. If you use VC software, it might be worth reading.

SVN is one of the saddest open source projects. So much effort when into
reimplementing CVS without its problems, totally missing that its key
problem is the underlying project model it implements.

Mercurial and Git seem to be slowly taking over, but it takes people I
while to get their heads around them.

Steve

Jerry wrote:
>http://www.joelonsoftware.com/items/2010/03/17.html is about version 
>control. If you use VC software, it might be worth reading.

He's got a point.  I just started using git in January, and it's quite good
for source code, from everything I can tell.  One problem I've noticed is
self-induced:  several weeks after touching a branch, I start to forget why
I made *it*, as opposed to about two dozen other branches. :-)

I'm wondering if it makes sense to continue using svn or similar for binary
files that cannot be merged (or at least not without great difficulty).  At
least then you even *can* lock it.  I'm thinking about PCB layouts, excel
sheets (bills of materials), etc., particularly proprietary files, but
non-line-oriented files in general, to a lesser extent.

The other concern I have (and there's probably an answer if I search, but I
don't care enough yet) is how much stuff I can shove into a git repo before
it becomes too slow.  I recall watching the Torvalds talk at Google (IIRC),
and he said giant things like KDE were a problem to put all in one place.

steveu <steveu@n_o_s_p_a_m.coppice.org> wrote:

>SVN is one of the saddest open source projects. So much effort when into
>reimplementing CVS without its problems, totally missing that its key
>problem is the underlying project model it implements.

I have used both, I find both usable, and in basic usage
they behave nearly identically.

What do you see as the key problem in the underlying model?

Steve

Steve Pope wrote:

> steveu <steveu@n_o_s_p_a_m.coppice.org> wrote:
> 
> 
>>SVN is one of the saddest open source projects. So much effort when into
>>reimplementing CVS without its problems, totally missing that its key
>>problem is the underlying project model it implements.
> 
> 
> I have used both, I find both usable, and in basic usage
> they behave nearly identically.
> 
> What do you see as the key problem in the underlying model?

1. They keep track of *files*, not *changes* to the files.
2. They have to keep everything in one dedicated place.

If the large project is branched out, merging between the branches could 
be a royal PITA in this model. As in the article suggested by Jerry, I 
have to do the code with zillion of if() and #ifdef instead of branching.


Vladimir Vassilevsky
DSP and Mixed Signal Design Consultant
http://www.abvolt.com

Jerry Avins wrote:
> http://www.joelonsoftware.com/items/2010/03/17.html is about version 
> control. If you use VC software, it might be worth reading.
> 
> Jerry

Well, I'm no expert in this although I've had to deal with it a bit.

What I don't understand is how merging "changes", including skipping 
"changes", can be easy because there may be interdependencies between 
them.  With versions presumably that can't be a problem unless there are 
branches.

Fred

Fred Marshall wrote:

> What I don't understand is how merging "changes", including skipping 
> "changes", can be easy because there may be interdependencies between 
> them.  With versions presumably that can't be a problem unless there are 
> branches.

Well I've been doing DVCS since about 2004 (GNU Arch) and I came to
it because of the merging and cherry picking possibilities.

For me merging a change happens when I have a stable main branch and
a development branch where I'm working on something new. Then, during
that new development I find something that needs fixing. I fix that
problem and commit it as a single commit and then merge it from the
the devel branch into the main.

Of course this only works if you are in the habit of committing in small
chunks and only commiting working code. I've been working this way for
some time and at times, when I'm really in the flow, I will do 10
or more commits an hour for 3 hours at a stretch.

HTH,
Erik
-- 
----------------------------------------------------------------------
Erik de Castro Lopo
http://www.mega-nerd.com/

Vladimir Vassilevsky  <nospam@nowhere.com> wrote:

>Steve Pope wrote:

[SVN and CVS]

>> I have used both, I find both usable, and in basic usage
>> they behave nearly identically.

>> What do you see as the key problem in the underlying model?

>1. They keep track of *files*, not *changes* to the files.
>2. They have to keep everything in one dedicated place.
>
>If the large project is branched out, merging between the branches could 
>be a royal PITA in this model. As in the article suggested by Jerry, I 
>have to do the code with zillion of if() and #ifdef instead of branching.

I guess I look at it from the other direction... it is
good to have as few branches as possible, and so one should
use whatever forms of polymorphism are available in
one's programming languages (including scripting languages,
build languages, etc.) to reduce the number of branches.

Better support for branches is of course good, because
sometimes you cannot avoid them.

Steve

>Vladimir Vassilevsky  <nospam@nowhere.com> wrote:
>
>>Steve Pope wrote:
>
>[SVN and CVS]
>
>>> I have used both, I find both usable, and in basic usage
>>> they behave nearly identically.
>
>>> What do you see as the key problem in the underlying model?
>
>>1. They keep track of *files*, not *changes* to the files.
>>2. They have to keep everything in one dedicated place.
>>
>>If the large project is branched out, merging between the branches could

>>be a royal PITA in this model. As in the article suggested by Jerry, I 
>>have to do the code with zillion of if() and #ifdef instead of
branching.
>
>I guess I look at it from the other direction... it is
>good to have as few branches as possible, and so one should
>use whatever forms of polymorphism are available in
>one's programming languages (including scripting languages,
>build languages, etc.) to reduce the number of branches.
>
>Better support for branches is of course good, because
>sometimes you cannot avoid them.

While endless branching is hard to see as a good thing, the "few branches
as possible" mentality mostly comes about *because* you have used CVS. It
has moulded your way of thinking, because it makes merging such a PITA.

Steve

steveu <steveu@n_o_s_p_a_m.coppice.org> wrote:

>While endless branching is hard to see as a good thing, the "few branches
>as possible" mentality mostly comes about *because* you have used CVS. It
>has moulded your way of thinking, because it makes merging such a PITA.

If you're going to merge a branch, why branch off in the first
place?

I have a little trouble conceiving of cases where branching
ever makes sense, other than political/legal situations
(i.e. you need to form a code base that is clean of certain IP,
for example).  And then you're probably not going to merge
later on, other than again from some political event (i.e.
a command decision by a project manager).

Polymorphism is there; use it.

Steve