Matthew Jacob wrote... > > Oh, very well, I'll have to say Perforce isn't that bad- it's just that it > doesn't have a snappy set of tcl/tk GUI tools that allow you look at whole > branch and revision histories..
I know there's a reasonable web-based tool that lets you look at revision histories for files, trees, whatever. There's also a nice tcl/tk tool that allows you to do merge files from a gui interface. > It doesn't have a 3-way filemerge tool (I > still fire up teamware (what NSElite became) to do heavy merging and use > the automerge feature)... Perforce *does* have the disparate release > stream feature, but I have found it somewhat difficult to use. Perhaps if > I'd actually had the depot locally I'd feel more at home with it.... What do you mean by 3-way merge? I've got one souce tree under perforce that is an amalgamtion of 5 source trees. Right now, I'm actively keeping it in sync with two separate source trees. And this is a non-trivial number of files -- each of the trees in question is at least a full FreeBSD source tree. Perforce's merging tools work pretty well, and have enabled me to do some branching and merging that would probably drive even a seasoned CVS user nuts. Here's how I generally merge things from two branches into a "combined" branch: p4 integrate -b branch1-to-combined-branch [ The -b argument specifies the branch mapping, which basically is the source and destination trees ] p4 resolve -as [ This tells perforce to resolve the merge, and accept "safe" changes. Safe changes are changes to files that have changed in the source or destination branches, but not both. ] p4 resolve [ This picks up the files that weren't automatically merged in the last step. For most files, perforce is able to merge things adequately, but when it can't, you have to go in and edit things manually, or specify whether you want to keep the source or destination branch version of the file. ] p4 submit [ Write a change description, edit the list of files to submit, and then check things in. ] You then repeat the same process for the second branch merge, except that in the first step, you'd use a different branch mapping. It's also pretty easy to merge things in the opposite direction. You can also do nifty things like only merge certain files from one branch to another, or only merge certain changes from one branch to another. It's possible, for instance, to merge revisions 4, 5, 7, and 9 of a file, but not 6 or 8. It's also possible to merge certain changelists from one branch to another, instead of doing a blanket merge. Ken -- Kenneth Merry k...@plutotech.com To Unsubscribe: send mail to majord...@freebsd.org with "unsubscribe freebsd-current" in the body of the message
