Who made me the Perforce-bitch? Here I am screaming "Subversion! Subversion!" and y'all think I just using that as cover for a p4 lover affair. :)
[Donovan Baarda wrote] > On Mon, 2005-08-08 at 15:49, Trent Mick wrote: > > One feature I like in Perforce (which Subversion doesn't have) is the > > ability to have pending changesets. A changeset is, as with subversion, > > something you check-in atomically. Pending changesets in Perforce allow > > you to (1) group related files in a source tree where you might be > > working on multiple things at once to ensure and (2) to build a change > > description as you go. In a large source tree this can be useful for > > separating chunks of work. > > This seems like a poor workaround for crappy branch/merge support. More like a pretty nice independent self-organizing feature that was necessitated as a workaround for a crappy solution (clientspecs) for huge data trees. > I'm new to perforce, but the pending changesets seem dodgey to me... you > are accumulating changes gradually without recording any history during > the process... ie, no checkins until the end. You want to do checkins of code in a consisten state. Some large changes take a couple of days to write. During which one may have to do a couple minor things in unrelated sections of a project. Having some mechanism to capture some thoughts and be able to say "these are the relevant source files for this work" is handy. Creating a branch for something that takes a couple of days is overkill. Perforce branching is pretty good in my experience. For very long projects one can easily create a branch. > Even worse, perforce seems to treat clients like "unversioned branches", > allowing you to review and test pending changesets in other clients. I'm not sure what you are talking about here. Yes, client information is stored on the server, but the *changes* (i.e. the diffs) on the client aren't so you must be talking about some other tool. Actually, if there *were* such a feature that would be quite handy. I'd love to be able to easily transfer my diffs developed on my Windows box to my Linux or Mac OS X box to quickly test changes there before checking in. > This supposedly allows people to review/test each others changes before > they are committed. The problem is, since these changes are not > committed, there is no firm history of what what was reviewed/tested vs > what gets committed... ie they could be different. The alternative being either that you have separate branches for everything (can be a pain) or just check-in for review (possibly breaking the build or functionality for other developers until the review is done). Actually the Perl guys working on PureMessage downstairs have two branches going in Perforce: one for checking into right away and then a cleaner tree to which only reviewed check-ins from the first are integrated. I'm not saying I am awash in pending changelists here. Nor that they should be used for what is better handled with branching. It is a tool (and a minor one). > Trying to develop and test a mixture of different changes in one > source tree is asking for trouble... they can interact. ...within reason. Trent -- Trent Mick [EMAIL PROTECTED] _______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com