Re: PostgreSQL 8.4 development plan

Tom Lane wrote: <blockquote cite="mid:20750.1202345935@sss.pgh.pa.us" type="cite"><pre wrap="">"Joshua D. Drake" <a
class="moz-txt-link-rfc2396E"href="mailto:jd@commandprompt.com"><jd@commandprompt.com></a> writes:
</pre><blockquotetype="cite"><pre wrap="">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.   </pre></blockquote><pre wrap="">
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</pre></blockquote><br /> My official role at my place of work is "configuration management
softwarearchitect". We primarily use ClearCase and I am responsible for the software side of the tooling around it. We
haveseveral 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.<br /><br /> Probably because I am spoiled - I don't understand
howyour teams get along so well with CVS. From my perspective, nearly everything available is better than CVS. If it
worksgood for you, and you don't ever have merging problems, or history tracking problems, then great - any move is
goingto be a hassle and will cause pain wasting at least some time in the next development cycle.<br /><br /> If you do
wantto see the benefit of change - here is my experience with Subversion:<br /><br /> I have been playing with
Subversionfor just almost two years now in a small group of people with 3 people on a small project. While working on
themain 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
reliefand 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
commitsis very weak in every production version of Subversion available today (1.4 and before) because Subversion does
notperform merge tracking. As soon as one begins using multiple branches, it becomes very difficult to keep track of
wherethings are, and the people who support Subversion are satisfied writing commit numbers in their comments to keep
trackof completed merges. Finally, because the concept of directories, branches, and tags have all been blurred into
onemuddle, horrible things happen if you try to do anything clever. In my case, I had a web project that I intended to
breakinto 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.
Itwas at this point that my frustration acceptance level was passed, and I switched to GIT. This was last December.
Subversion1.5 was supposed to be out to address many of these issues, but it was a hollow promise as it was still not
releasedthe last time I checked, and a review of their discussions on the matter show that many of the promises they
madewere likely premature.<br /><br /> Since then, I have been consistently impressed with GIT. I have completed
complexmerges and extensive parallel development that would have been painful or impossible with Subversion. I am not a
fanof de-centralization as most GIT supporters are - but I am a fan of full feature change sets. In GIT I can merge a
changeset back and forth between branches and it will track it. I can rebase the change set to a later baseline and
continuemanipulating it. I can save my work space aside, or use the same work space to switch to another branch and
havemy uncommitted work automatically three-way merged to the new context. Our team on this outside work project is now
upto 5 people and everybody likes GIT better than Subversion.<br /><br /> My story is that Subversion is cute - but it
doesnot scale in terms of flexible parallel development models, nor does it provide sufficient functionality over CVS
tobe considered "the best thing since sliced bread." It is an improvement over CVS, but it is not a great tool. If you
aregoing to go through the effort of migrating to another system, I would seriously consider the benefits of other
systemsout there before believing that Subversion is the answer to all problems. GIT is one good choice. However, my
experiencewith these products in insufficient to make a recommendation for PostgreSQL. I would like to experiment with
Hgand a few others over the next few months and see what I think of these.<br /><br /> I encourage all to keep their
mindsopen.<br /><br /> Cheers,<br /> mark<br /><br /><pre class="moz-signature" cols="72">-- 
 
Mark Mielke <a class="moz-txt-link-rfc2396E" href="mailto:mark@mielke.cc"><mark@mielke.cc></a>
</pre>