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 -- [email protected] http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-list
