Forwarded w/ assumed permission: This is where I come from on my p4 prejudice on branching, but ClearCase, and even old PVCS are better than svn. There are ways of doing things that put more or less power at the user's disposal. A paper card file in a library will help you find books, but not as well as an on-line database. Likewise, you can store historical data in Word docs or SharePoint (particularly sore points for me right now), but not be able to recover that data in reports except by human search and tally.
So why have computers if we don't use them? p4 has a BDB back end, and so does svn. But p4 gives me data in that DB that allows tracking merges, using changesets for integration, dynamic and rapid tags, and will give me management data on questions no one's thought to ask yet. svn, using the exact same back end, doesn't do any of that. Why? Because the svn developers (1) wanted a drop in for cvs, and (2) because they fell in love with their "lazy copy" facility. They missed a chance to do something really special, and now they're stonewalling those who ask them to reconsider. As for M$ developers being crybabies, you don't have to convince me. Were you at the meeting where Kral spent 20 minutes calculating his lost productivity if he had to spend 1.5 seconds toggling from his precious IDE to a p4 front end? It made "Office Space" look like cinema verite ... you can't make stuff like that up. On Wed, October 24, 2007 9:44 am, MattyJ wrote: > TortoiseSVN: Great tool. I use it quite extensively in my private repository. However, in a Microsoft-centric world, developers use VisualStudio for everything and if you breach the paradigm of the SCC API, you have an uphill battle on your hands. And a very steep one. I wasn't ready for that fight. > > Also, as I said, I loved AnkhSVN when I was using it for demo purposes, but at the time (two years ago) it was prone to crashing and there were some minor conveniences missing. I'm sure it's better now (if it's still around, I haven't checked.) It's really a philosophical issue with developers that have drunk the Microsoft Kool-Aid. If they right click on a file and it doesn't have the familiar SCC options there, the tool is automatically tossed out. > > Branching: I guess what you allude to is true, I really meant merging. Branching and versioning of the repo is easy to understand (for me) and I think a good scheme, but I want the repo to know what I've already merged so I don't have to worry about it. Even if you have rules about checkin comments, etc., I don't trust them. Even when they are my own. Especially when they are my own. :) (Perforce and ClearCase bias speaking here, big time.) > > > -Matt > > > > On Wed, 24 Oct 2007 08:28:42 -0700, Lan Barnes <[EMAIL PROTECTED]> wrote: > >> On Tue, October 23, 2007 5:26 pm, Christian Seberino wrote: >>> >>> Lan Barnes wrote: >>>> Thanks, Matt, solid experience to share. I am forwarding it. >>>> My major gripe is the lack of true (data based) version labels. >>> >>> Can't the "memo" for a version serve that purpose? >> >> Not unless you can do a code pull by memo >> >>> >>>> Also, I've >>>> become quite fond of change sets, and can't remember if svn supports >> those. I tend to drop SW as soon as I decide it doesn't have the facilities I need. >>> >>> Not sure what a changeset is. Do you mean an easy way to find the >> difference between 2 versions? svn diff can do that for you. >>> >> >> You are correct, you don't know what a change set is. On a full feature tool, check ins are recorded as a set of affected files. This allows you to (for example) check in sequentially fixes A, B, and C, and then later roll back change A w/o disturbing the integrity of changes B and C. There >> are other uses almost as powerful. >> >>> >>>> But svn is a godsend to web based OSS projects. >>> >>> Why is svn great for *web* based projects? >>> >> >> As I typed that, I knew I was using a bad term. I didn't mean projects of >> web based apps. I meant typical OSS projects that are oriented towards having a project web site w/ repository and diverse contributers checking >> in code over the internet. Sorry, my bad. >> >> ************* >> >> From here on down your remarks are made to Matt's observations, and I won't speak for him. But I will point out that what he decries below is a >> lack of merge/branch/integration HISTORY. svn has no tracability in its "branching" which is hardly surprising, since their concept of a branch is >> to make a copy and give it a different name. That's something you could do >> with floppy disks stored in a desk drawer. Not really what we do in the business, where we need to support traceable selective merges or code copies between multiple branches of the same or different projects. And it >> all has to be efficient, traceable, and auditable, especially when 3-letter gvmt agencies might swoop in at any minute and demand you to prove that you know what's in your medical device/military SW. It also helps if it's not so complicated that it gives everyone headaches. >> >> I don't want to sound condescending, Chris. Forgive me if this comes across that way. But SCM has come a LONG way in the time I've been it. There's a hell of a lot more to it today than just storing copies of old code. But unless you work in a shop where up to date practices are demanded (defense, medical, DoT, etc), and unless your local PHBs are enlightened, it's likely you're stuck in a dark place where SCM is considered a speed bump, police work (gag), or an unecessary expense. >> >> Properly done, SCM more than pays for itself in saving time, money, and defects discovered by customers, which are VERY expensive, especially if the customer dies and your factory gets padlocked and the family sues .... >> >>>> A buddy of mine worked in a commercial shop that used Svn, and he >> agrees >>>> that it's not ready for the enterprise. The lack of >>>> merge/branch/integration history was a real pain in the rump for him. >>> >>> Not sure what you mean....every commit and every branch creation >> requires >>> creation of comments and history to go along with it. >>> >>>> It also lacks (lacked?) a decent integration with Microsoft tools. >>> >>> TortoiseSVN? >>> >>>> I didn't >>>> even consider deploying it at my current company because I knew we'd have >>>> at least a couple of branches, and literally some sort of deployment every >>>> day. I wouldn't have time for anything else but Svn admin. >>> >>> Creating a branch is easy in SVN. Not sure what your problem is with >> branches. Merging is bad in SVN but I heard they are working on that. >>> >>> cs >>> >>> >>> -- >>> [email protected] >>> http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list >>> >> >> > > > -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- Lan Barnes SCM Analyst Linux Guy Tcl/Tk Enthusiast Biodiesel Brewer -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
