On Fri, August 17, 2007 2:10 pm, Paul G. Allen wrote: > On Fri, 2007-08-17 at 12:44 -0700, Lan Barnes wrote: >> On Fri, August 17, 2007 12:30 pm, Stewart Stremler wrote: >> > begin quoting Lan Barnes as of Fri, Aug 17, 2007 at 07:34:43AM -0700: >> >> >> >> On Thu, August 16, 2007 9:30 pm, Stewart Stremler wrote: >> >> > begin quoting Andrew Lentvorski as of Thu, Aug 16, 2007 at >> 06:25:20PM >> >> >> Stewart Stremler wrote: >> >> >> >Get a good three-way merge program. >> >> >> >> >> >> Or use git, mercurial, darcs, perforce, etc. rather than >> subversion. >> >> > >> >> > Merging still sucks. >> >> >> >> Merging can be minimised, suck-wise, by having developers understand >> the >> >> tofu rule, keep branches short, only branch when necessary, etc. >> > >> > Well-trained developers and limited tasks can get rid of a lot of >> > suckages; but even then, circumstances can make any sort of merging >> > painful. >> > >> > If you give me well-trained developers that can be trusted to >> understand >> > some concept, and the administrative support needed to keep branches >> > short / branch when necessary... >> > >> > I'd probably do away with branches altogether. >> > >> > I'd train the developers in refactoring first. Small changes that >> don't >> > change observable behavior can be made to the common tree. No need to >> > branch the source to rewrite a module... rewrite it in place, using >> > refactoring techniques. >> > >> > Next I'd use the administrative support to at least acquire or >> configure >> > a side-by-side two-way merge system (and train the developers on it), >> or >> > use a version control system that provides a three-way-merge tool. >> > >> > >> >> I completely agree with you. Philosophically, I advocate developing on >> the >> trunk and branching ONLY when two code lines MUST be kept separate, at >> least for a time. >> >> That said, one must branch sometimes. And the lack of true branching is >> part of svn's problem. Copies are not branches (nor are they tags/labels >> -- they are at best snapshots). >> > > Which is one thing I didn't like about being told I had to start using > SVN instead of Perforce. Last week I just finished branching some code > for a pair of test utilities. The two utilities are based upon the same > code base, but I had two different projects and two different depots > (repositories) in Perforce. When I found a bug in one, I had to checkout > the other, copy the code over, and then check it in. Not to mention go > through another set of testing. I was doing everything twice. > > So, I took the most up-to-date code from ProjA and branched it to ProjB. > I then checked out ProjB, and replaced it with the real ProjB code. I > made my changes to ProjB, fixing bugs and adding the required features, > all of which will also apply to ProjA. Now, I can use the Integrate > command to integrate ProjB with ProjA, and Perforce will help me apply > the changes to the original code. > > With SVN, I can't do that. I was also using labels and jobs in Perforce, > which I will no longer be able to do. > > PGA >
Yup. I had such high hopes for p4 once ;'-( Now I guess I have to transfer all my hopes and fears over to this git thingie. (Or suck it up and do one of my own. I think I'll call it "Perversion.") -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
