Re: PostgreSQL 8.4 development plan

Tom Lane wrote:
> "Joshua D. Drake" <jd(at)commandprompt(dot)com> writes:
>
>> O.k. I am not too interested in starting a whole war here (again) but
>> for the record, we have what appears to be a perfectly working
>> capability to move from cvs to svn. So *if* review board is something
>> we really like, the SCM should not be the barrier.
>>
>
> I believe the compromise that's been reached for the moment is that
> the core SCM will remain CVS, because everybody's favorite other SCM
> can import from CVS but not necessarily from somebody else's favorite
> other SCM. So a diff tool that doesn't work with CVS isn't going to be
> especially useful for us.
>
> I would imagine that the problem is mostly a lack of round tuits,
> and that if we really fell in love with review board we could probably
> teach it to handle diffs against CVS (especially seeing that the rest
> of it besides post-review already works with CVS, supposedly).
>
> So, again, the question is has anyone really used it? Is it the
> best thing since sliced bread, or not so much?
>
> regards, tom lane

My official role at my place of work is "configuration management
software architect". We primarily use ClearCase and I am responsible for
the software side of the tooling around it. We have several thousands
users and terrabytes of data stored from millions of change sets. Not
that roles or anything matter, but where your job is PostgreSQL, my job
is SCM.

Probably because I am spoiled - I don't understand how your teams get
along so well with CVS. From my perspective, nearly everything available
is better than CVS. If it works good for you, and you don't ever have
merging problems, or history tracking problems, then great - any move is
going to be a hassle and will cause pain wasting at least some time in
the next development cycle.

If you do want to see the benefit of change - here is my experience with
Subversion:

I have been playing with Subversion for just almost two years now in a
small group of people with 3 people on a small project. While working on
the main branch ("trunk") submissions were generally smooth. Conflict
resolution is poor without graphical tool support, but with only three
people and co-ordinated work this was rarely an issue. Atomic
submissions were a pleasant relief and performance was adequate. Commits
are not at the level of functionality that I am accustomed to though.
First, commits are not registered until a person is complete their work
and the work is submitted. Second, merging of commits is very weak in
every production version of Subversion available today (1.4 and before)
because Subversion does not perform merge tracking. As soon as one
begins using multiple branches, it becomes very difficult to keep track
of where things are, and the people who support Subversion are satisfied
writing commit numbers in their comments to keep track of completed
merges. Finally, because the concept of directories, branches, and tags
have all been blurred into one muddle, horrible things happen if you try
to do anything clever. In my case, I had a web project that I intended
to break into web, lib, and source. I renamed trunk to trunk/www and
created trunk/lib, and trunk/source. For this point forwards, I was
completely unable to merge changes from other branches to trunk.
Subversion became completely confused. It was at this point that my
frustration acceptance level was passed, and I switched to GIT. This was
last December. Subversion 1.5 was supposed to be out to address many of
these issues, but it was a hollow promise as it was still not released
the last time I checked, and a review of their discussions on the matter
show that many of the promises they made were likely premature.

Since then, I have been consistently impressed with GIT. I have
completed complex merges and extensive parallel development that would
have been painful or impossible with Subversion. I am not a fan of
de-centralization as most GIT supporters are - but I am a fan of full
feature change sets. In GIT I can merge a change set back and forth
between branches and it will track it. I can rebase the change set to a
later baseline and continue manipulating it. I can save my work space
aside, or use the same work space to switch to another branch and have
my uncommitted work automatically three-way merged to the new context.
Our team on this outside work project is now up to 5 people and
everybody likes GIT better than Subversion.

My story is that Subversion is cute - but it does not scale in terms of
flexible parallel development models, nor does it provide sufficient
functionality over CVS to be considered "the best thing since sliced
bread." It is an improvement over CVS, but it is not a great tool. If
you are going to go through the effort of migrating to another system, I
would seriously consider the benefits of other systems out there before
believing that Subversion is the answer to all problems. GIT is one good
choice. However, my experience with these products in insufficient to
make a recommendation for PostgreSQL. I would like to experiment with Hg
and a few others over the next few months and see what I think of these.

I encourage all to keep their minds open.

Cheers,
mark

--
Mark Mielke <mark(at)mielke(dot)cc>