* Andrew Dunstan <and...@dunslane.net> [090605 14:41]: > The whole point is that we want something better *that suits our work > patterns*. Almost all the backpatching that gets done is by the > committers. So we have a bunch of concerns that are not relevant to that > vast majority of developers. In particular, it would be nice to be able > to make a bunch of changes on different branches and then commit it all > in one hit. If that's possible, then well and good. If it's not, that's > a pity.
My only concern is that I am seeing 2 requirements emerge: 1) Everything has to work as it currently does with CVS 2) We want better information about how patches relate for possible future stuff Unfortunately, those 2 requirements are conflicting... If you (not anyone personally, but the more general "PostgreSQL committer") want the repository to properly track the "fixes" and show their relationship, and extra through all the branches than you really do want the "branch-to-fix" and merge the fix forward into all your STABLE/master branches, like the "daggy" type thing mentioned elsewhere... But notice, that is *very* different from the current work patterns based on the CVS model where everything is completely independent (save the commit message), and it's a huge change to the way developers work. If you want to stay with the current CVS style, then you aren't going to get any closer than "commit messages matching" (or possibly a reference to another commit as an extra line) that we currently have with CVS. My suggestion is to keep it simple. Just work independently, like you currently do. You don't want every committer to have to completely learn the advanced features of a new tool just to use it... You can use it as you use the less feature-full tool as you learn all the features... But as people start to use the new tool, and start to use it's more advanced features, then it's natural that their results will start to be reflected the main repository. But insisting that people currently comfortable and proficient in the current work patterns *have* to learn completely new ones for a "flag-day" type switch and start using them immediately is going to: * Piss them off * Create great ill-will against the tool And neither of those will be the fault of the tool itself, but of the way a "new process" was forced in conjunction with a new tool... I don't want to see the PG project trying to *force* a radical change in the way the development/branches currently work at the same time as a switch to git. Replace the tool, and allow the current processes and work-flows to gradually improve. The process and work-flow improvements will be an iterative and collaborative process, just like the actual code improvements, where huge radical patches are generally frowned upon. I've used git for a long time, on many different projects. I do know how radically it *can* change the process, and how much more efficient and "natural" the improved processes can be. But the change is not an overnight change. And it's not going to happen unless the people needing to change *see* it's benefits. And that's going to take time and experience with the new tool... Anyways, I said previously that I was over with this thread, but now I mean it ;-) If someone want specific git information or help, I'm available. a. -- Aidan Van Dyk Create like a god, ai...@highrise.ca command like a king, http://www.highrise.ca/ work like a slave.
signature.asc
Description: Digital signature