On 2011.1.28 5:15 PM, H.Merijn Brand wrote:
> On Fri, 28 Jan 2011 10:03:10 +1000, Michael G Schwern
>> 1972 SCCS The first version control system
>
> We actively used SCCS up to 2009.
Sometimes I think you work in a computer museum, but nobody told you. ;)
>> 1982 RCS The first vaguely sensible version control system
>>
>> 1986 CVS Now people can work on multiple files AT THE SAME TIME
>>
>> 1990 CVS adds branching
>> 1995 CVS adds anonymous network access. Open Source development as
>> we know it is now possible
>
> Where is bitkeeper in this list? Wgere is perforce in this list?
Perforce was in 1995. Its difficult network model might be a consequence of
having come just as CVS was introducing anonymous access, so it may not have
been obvious that was necessary.
Larry McVoy was talking about BitKeeper in 1998 and Linux took it on in 2002.
It was designed at the tail end of the CVS era, when the model had broken
down for Linux.
On 2011.1.28, Nick Clark uttered:
> So how does one actually commit a refactoring?
> How do I write a test that fails under the previous, functionally identical
> code base?
Oh, you could configure a change with exceptions. Part of the Aegis system
was that you had to declare and describe each change before you made it. It
was part issue tracker as well. It was part everything. Review manager.
Integration manager. Change manager. It defined and controlled your whole
workflow.
On 2011.1.28, David Cantrell exclaimed:
>> I propose it benefited from all the folks who
>> happily and easily used "svn cp" and then found no sane way to merge back.
>
> I have to ask what all those folks are doing wrong.
What were they doing wrong? They were using Subversion before 2008 when they
introduced built in (and rather lame) merge tracking in 1.5. SVN existed for
SEVEN YEARS with easy branching but difficult merging. You had to try and
make things like svnmerge.py work or use svk or (I'm not making this up) write
your own merge tracker. I had to write a merge tracker for SVN.
The pre-1.5 merge would only work if you branched, worked and then merged. If
you branched, worked, pulled in some updates from upstream, worked some more,
and then tried to merge you were hosed. SVN did not track your pull, so it
would try to merge the diff from the beginning of the branch, get confused
because it saw the same change twice, and cause bogus conflicts.
--
You know what the chain of command is? It's the chain I go get and beat you
with 'til you understand who's in ruttin' command here.
-- Jayne Cobb, "Firefly"
