Multi-User Subversion

Subversion vs CVS by Slashdotess · 2002-12-20 19:10 · Score: 3, Insightful

Sorry, I'm not exactly a professional developer but:

Whats the advantage to killing the standard of CVS, that seems to work well today? I mean, are the features of this "Subversion" make it worth the switchover?

Re:Subversion vs CVS by Cebu · 2002-12-20 19:28 · Score: 5, Informative

CVS is weak at best with a long standing list of quirks, bugs and missing features. The current architecture and code base is in such state where many opt to not make the attempt at crowbar many of these features and fixes into CVS. In CVS, security is non existant, branching takes up a lot of unnecessary resources and quite a great deal of time, lacks meta data like directory revisioning along with various other usefull items, stores useless CVS data in the repository and has a tendancy towards being slow. The worst, inexcusable, flaw in CVS is the complete lack of atomic commits.

On the flip side, I do not suggest using Subversion for any critical project at this point since they are not feature complete for their first release and their bug list, frankly, scares me.
Re:Subversion vs CVS by bdash · 2002-12-20 19:30 · Score: 5, Interesting

A good discussion of this was in Linux Journal recently.

Briefly, CVS lacks version control across file renames, has some issues with binary files, and the CVS code base has serious design issues.
Re:Subversion vs CVS by mccalli · 2002-12-20 19:59 · Score: 5, Informative

Well, I am a professional developer, and I have to say that CVS amongst the 'worst' of the source control systems I've used. That sounds incredibly critical, but I really don't mean it in a disrespectful sense. A need for a freely available, open source control system was there, and CVS filled and continues to fill it well. Better than SCCS and RCS ever did. Despite that however, its functionality is a little lacking compared to most commercial rivals.
Directory handling springs to mind, as does renaming files. Atomic commits too. As well, there's also the fact that you often end up editing the modules files directly - an end-user should never have to care about a program's internal storage of meta-data.
Now, I haven't used Subversion so I am unable to make a comparison. I understand it handles directory versioning better, but I'm not aware of the rest of the points I made. The directory handling alone is a huge plus however, so it's a project whose announcements I'm following closely.
Cheers,
Ian
Re:Subversion vs CVS by noselasd · 2002-12-20 23:29 · Score: 5, Informative

From the docs, compare with CVS. Remember that many of the Subversion deveoplers are/were CVS developers..
* Real copies and renames. The Subversion repository doesn't use
RCS files at all; instead, it implements a 'virtual' versioned
filesystem that tracks tree-structures over time (described
below). Files *and* directories are versioned. At last, there
are real client-side `mv' and `cp' commands that behave just as
you think.

* Atomic commits. A commit either goes into the repository
completely, or not all.

* Advanced network layer. The Subversion network server is Apache,
and client and server speak WebDAV(2) to one another. (See the
'design' section below.)

* Faster network access. A binary diffing algorithm is used to
store and transmit deltas in *both* directions, regardless of
whether a file is of text or binary type.

* Filesystem "properties". Each file or directory has an invisible
hashtable attached. You can invent and store any arbitrary
key/value pairs you wish: owner, perms, icons, app-creator,
mime-type, personal notes, etc. This is a general-purpose feature
for users. Properties are versioned, just like file contents.
And some properties are auto-detected, like the mime-type of a
file (no more remembering to use the '-kb' switch!)

* Extensible and hackable. Subversion has no historical baggage; it
was designed and then implemented as a collection of shared C
libraries with well-defined APIs. This makes Subversion extremely
maintainable and usable by other applications and languages.

* Easy migration. The Subversion command-line client is very
similar to CVS; the development model is the same, so CVS users
should have little trouble making the switch. Development of a
'cvs2svn' repository converter is in progress.

* It's Free. Subversion is released under a Apache/BSD-style
open-source license.
Re:Subversion vs CVS by syphoon · 2002-12-21 00:34 · Score: 4, Informative

Although there is a definite place for the "If it ain't broke, why fix it?" philosophy, its also equally often a good time to remember there was nothing broken about the horse and cart. While CVS is a good stable system that has many times over proven its worth, we also have to recognise there _are_ features lacking and issues that if corrected, would allow for greater productivity. Such as the binary file handling. Binary support in Subversion looks to be a _LOT_ easier than in CVS. Currently CVS always transmits binary files in full. And CVS does have networking issues.File differences are sent in only one direction, from the client to server, but not the other way round. And because of CVS's codebase, which is very ugly (not surprising given its history of being layers of hacks), it becomes increasingly hard to add new features. In short, we've approached the stage with CVS where a complete overhaul and restart would be better longterm.

sounds cool by farnsworth · 2002-12-20 19:25 · Score: 4, Interesting

subversion sounds like a really cool tool. I've been following it for about a year now. it has some great advantages over cvs, such as multi-file atomicity, and good support for refactoring.

I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.

--

There aint no pancake so thin it doesn't have two sides.

Re:sounds cool by stefanlasiewski · 2002-12-20 21:00 · Score: 4, Insightful

If you're interested in clients, check out the http://scm.tigris.org/ pages: There's a GTK and a cross-platform GUI in the works (And I've seen a few other GUIs on elsewhere (sourceforge?)

--
"Can of worms? The can is open... the worms are everywhere."
Re:sounds cool by joib · 2002-12-20 22:34 · Score: 4, Insightful

I really hope that building ancillary tools like nice clients (wincvs) and useful add-ons (bonsai) is easy enough to do, because that's really where the critical mass is wrt widespread adoption.

Most of the subversion functionality is actually in a library, which makes it a lot easier and more robust to build gui clients and such for subversion. CVS, by comparison, is only accessed through the command-line client, so cvs gui clients have to execute the cvs binary and then parse the output, which as you certainly can imagine, is cumbersome.

Atomic checkins are a must... by dagg · 2002-12-20 19:28 · Score: 5, Informative

Something that is great about Subversion is that it has atomic checkins. That means if something goes wrong while you are checking in a file, then your checkin is rolled back. That is super-handy, and brings it up to par with Perforce (a commercial revision control system that I've used in the past).

If something goes wrong during a CVS checkin, then all hell can break loose.

--
Sex - Find It

Re:Atomic checkins are a must... by dagg · 2002-12-20 21:07 · Score: 3, Informative

I'm not sure where you got that idea. There is no connection, whatsoever, to my knowledge. Here is a comparison page provided by the Perforce folks: comparison chart.

--
Sex - Find It
Re:Atomic checkins are a must... by Krellan · 2002-12-20 23:07 · Score: 4, Interesting

Another use of atomic checkins is checking in more than one file at a time, especially when checking in two files whose changes depend on each other. In my experience at several CVS shops, the build sometimes breaks simply because of unfortunate timing: checking out the tree while someone else is in the middle of checking in a series of files. Most shops deal with this manually, by having certain rules, such as no checkins allowed at all during a certain hour of the night.

If there was a way in CVS to begin a transaction, then do multiple checkins, then commit/rollback that transaction atomically, that would be wonderful. It would be impossible for one person to check out someone else's partial checkin.

If Subversion is getting this feature, or even has this already, it will be one of the best "selling points" to replace CVS!

--
Dr. Demento On The 'Net!
Re:Atomic checkins are a must... by roskakori · 2002-12-21 00:40 · Score: 3, Informative

[atomic checkins are] super-handy, and brings it up to par with Perforce

while perforce is not open source, they still grant a free license for 2 clients. this is enough for toying with my g4 and ibook. additionally, all the manuals are online, and so are ports for many different systems. there are plugins for many ides, and a web-gui based on html-forms. what i like the most is the relative ease of use of all parts involved.

until someone comes up with a stable and usable open-source tool, perforce might serve any home-user's needs.

Subversion is far better than CVS by cartman · 2002-12-20 19:43 · Score: 5, Interesting

The fundamental design of CVS is flawed, and this leads to anomolous behavior. Becase the problem with CVS is in its design, not its current implementation, a re-design and corresponding re-write is reqiured.

For example, CVS stores its repository in a series of diffs in a directory structure, and the directory structure parallels the development tree. The difficulty is, directories in the cvs backend are therefore not versioned! Thus, moving files around, and re-working the tree, are not handled correctly in cvs. In subversion, the entire repository (dirs, files, and all) is stored as a single coherent revision; a subversion repository is an array of coherent tree/file groupings. As such, correct handling of directories occurs automatically. Also, atomic commits (something cvs lacks) are handled much more easily in this model.

Let me also say that the design of subversion is absolutely excellent. The design is properly decoupled and properly abstracted. Architecturally, it is greatly superior to cvs, and substantially superior to several commercial alternatives. I would imagine that the low-end source control products (PVCS, SourceSafe) will have significant difficulty staying alive once Subversion is widely deployed and tested.

Re:Subversion is far better than CVS by g4dget · 2002-12-21 01:55 · Score: 3, Insightful

But this new file does not have the history of the old file,
It does if you add it (or automate adding it with a simple cvs-rename script). However, it's not clear that that matters much.
you can not check out last weeks version of it
Sure you can: if you ask for last weeks version of the software, it will contain the file under the old name. If you ask (somehow) for the individual file, CVS will tell you that it didn't exist at that time, which is correct and consistent. It would be inconsistent if I got a week old version of "newname.c" if "newname.c" didn't exist at that time. I do hope Subversion doesn't do that.
and it is not included in diffs of changes that spanned multiple files.
Huh? Of course, it's included. The diffs will contain a deletion for the old file and an addition for the new file. That is exactly what should happen. I don't think "diff" even supports any other way of renaming.
Deleting and adding, though it may be well-defined, is also a really ugly and non-intuitive way of doing it.
Well, your message suggests to me that handling renaming any other way than the way CVS does may actually be worse.

Re:$Revision$ by xlv · 2002-12-20 20:06 · Score: 4, Informative

You could use the LastChangedDate or LastChangedRevision tags. This is taken from the manual:

LastChangedDate

The last time this file changed. Can also be abbreviated as Date. The keyword substitution of $LastChangedDate$ will look something like $LastChangedDate: 2002-07-22 21:42:37 -0700 (Mon, 22 Jul 2002) $.

LastChangedRevision

The last revision in which this file changed. Can be abbreviated as Rev. The keyword substitution of $LastChangedRevision will look something like $LastChangedRevision: 144 $.

arch by bedessen · 2002-12-20 20:18 · Score: 5, Informative

Of course, no discussion of CVS's strengths and weaknesses vs. Subversion would be complete without mention of the third contender, arch. Link 1, Link 2.

CVS still awfully nice by 0x0d0a · 2002-12-20 20:27 · Score: 4, Informative

If you're a coder, and have never used CVS, try it. It's absolutely lovely. "Oh, introduced a bug there...let's just diff against a known good version." "Oh, it looks like *Bob* was the one to commit that broken code." "Why did I add *that* code? Let me check my CVS log..."

Yeah, there are probably things about CVS that could be better. But if you've never used it, and aren't already using a competitor, it's really good.

--
May we never see th

Re:CVS still awfully nice by Cuthalion · 2002-12-20 21:39 · Score: 4, Informative

cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.

Public service announcement

If you're in windows and trying CVS, check out tortoise

--
Trees can't go dancing
So do them a big favor
Pretend dancing stinks!
Re:CVS still awfully nice by Anonymous Coward · 2002-12-21 03:22 · Score: 3, Funny

Yeah, there are probably things about CVS that could be better. But if you've never used it, and aren't already using a competitor, it's really good.

That's what middle-school geeks used to say about BASIC.
Re:CVS still awfully nice by dubl-u · 2002-12-21 05:40 · Score: 3, Funny

cvs is way better than no version control. agreed. hell, PVCS and Source Offsite (the two worst version control systems I've ever used) are still way better than no version control.

On a project with more than two developers, quitting to work the fryer at McDonald's is way better than no version control.

some experiences by Tom · 2002-12-20 21:01 · Score: 5, Informative

I've been moving all of my CVS development over to Subversion over the past few months, including a couple development servers at my company.

Since Subversion is now in Debian unstable, it's really easy to install. Compiling from source is a bit of a hassle due to all the dependencies, especially on the apache2 libs.

So far, I've not had a bad experience. No data loss or anything. And I'm very, very happy that I can finally get rid of pserver.

Subversion impressed our company developers by its speed (subjectively, considerably faster than CVS for comparable operations) and its user-friendlyness. It's the details, stuff like automatic detection of binary files, that makes life for the dev people easier.

For the admin, the fact that it runs via apache2 makes your life much easier, especially when it comes to firewalling and access control (user and passwords, etc.) - in a corporate network, you could easily plug it right unto your LDAP server for authentication, for example.

Two things are holding Subversion back right now, IMHO:

a) lack of a wincvs/tkcvs equivalent. Rapidsvn is making progress, but it's still very much alpha.

b) a couple things still missing, like understanding symlinks.

--
Assorted stuff I do sometimes: Lemuria.org

Aegis aegis aegis aegis aegis! by Anonymous Coward · 2002-12-20 22:29 · Score: 5, Informative

Check out Aegis - http://aegis.sourceforge.net. It's better than Subversion. It's older than Subversion. It's more stable than Subversion. It has atomic multi-file commits. Branching to any depth. Multi-user support. Distributed support. Applying change sets to multiple repositories. And much, much more.

Re:Aegis aegis aegis aegis aegis! by Dominic_Mazzoni · 2002-12-21 08:22 · Score: 3, Insightful

Aegis sounds like a nice system, but it doesn't even run on Windows, nor did it ever run on Mac OS 8/9. CVS runs on everything, and Subversion is designed to be extremely portable, too. Sorry, but that's a critical requirement of a lot of developers - even open-source developers, because lots of us want our open-source programs running on as many platforms as possible.

Al Viro's review of subversion by hellgate · 2002-12-20 23:01 · Score: 3, Informative

Damn you. That thread got me to download subversion source and read it -
mistake I won't repeat any time soon. I've spent several months wading
through fairly disgusting code - block device drivers are not pretty,
ditto for devfs. I had more than once found myself grabbing Lovecraft
to read something that would be less nightmare-inducing. But _THAT_ takes
the fscking cake - I don't _care_ what Larry (or anybody else for that
matter) does to people who had excreted that code. No, wait - I _do_ care.
I want video of the... event.

I don't use BK, but you can be damn sure that I won't touch SVN. Ever.

Short and concise as ever.

http://marc.theaimsgroup.com/?l=linux-kernel&m=1 03 402696209262&w=2

Non-Apache 2 server? by g4dget · 2002-12-20 23:52 · Score: 3, Interesting

The use of Apache 2 is a show-stopper as far as I'm concerned: we have no interest in migrating to Apache 2 in the foreseeable future. Is there a small, simple standalone server for subversion, or can I run it over ssh? Does subversion work with non-Apache WebDav implementations? Is there a CGI version of its server component?

In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.

Re:Non-Apache 2 server? by theefer · 2002-12-21 01:17 · Score: 3, Informative

If you work on a local machine, you can use simple "urls" like file:///var/svn/myrepos/ instead of the http://server/svn/myrepos/, and the Subversion people are now working on new network layer, libsvn_ra_svn, which offers a new networking layer (svn://blahblah/).

A standalone subversion server is also in development, but I don't remember if it's scheduled for 1.0 or not. However, this is free software, if you feel like you need it, you can help developping it ! :-)

The point is, this is indeed a good remark, but not a showstopper. And the Apache2 svn server works just perfect for me !

--
theefer
Re:Non-Apache 2 server? by RupW · 2002-12-21 03:06 · Score: 3, Interesting

In comparison, CVS over ssh is secure and works pretty much everywhere. Many machines don't need to run a web server, let alone Apache 2, while ssh pretty much runs everywhere.

As noted above, there is a standalone protocol in development. There's also a pipe module to exactly mimic cvs over ssh.

If you strip down apache's configuration enough, it doesn't eat too many resources, though (can't get exact numbers from here, sorry) and it pretty much runs everywhere itself.

I'm doubtful (for now). by g4dget · 2002-12-21 00:00 · Score: 4, Insightful

People like to complain endlessly about CVS and its quirks. And, yes, it does have quirks. But CVS mature, it works, and its quirks really don't affect day-to-day development in most environments.

Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.

It's been years since we have had any signficant problems with CVS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to subversion would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Subversion to give me enough confidence in it to try it.

Re:I'm doubtful (for now). by theefer · 2002-12-21 01:36 · Score: 5, Interesting

Subversion does look somewhat better and cleaner than CVS. But there are lots of add-on tools for CVS that will need to get ported (GUIs, servers, web interfaces, IDE integration, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--CVS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.

Good point, but this is also a big concern of the Subversion folks. This is why subversion looks so much like CVS. The commands and aliases are almost all the same, and a great part of the comportment the users see also is.

The ViewCVS scripts has already been ported to SVN, though it's not perfect yet, it does work. The GUI is pretty much in development indeed : RapidSVN is a working one, yet not complete either. An Emacs mode, similar to the CVS mode, shouldn't bee too hard to code I suppose, this is just a matter of time, will, and knowledge of elisp :)

There was talkings about using SVN as a backend for a wiki too, this could be fun and really nice. A first draft had been coded by Greg Stein (if I'm not mistaken), but it was mostly test stuff.

Subversion still needs help and contributors. People keep whining about CVS not handling file renaming etc, and they also keep using complicated tricks to avoid those flaws. I know, I've done it too. The very same people look at subversion and say "mh, nice, but not mature yet, let's wait it grows up a little". I doubt it'll grow quickly on its own, it just needs some help from all these coders who *will* use it in a few months/years !

Believe me, once you've switched to svn, it just looks life is *so* easier. Try it, it won't bite, and you'll most likely love it !

--
theefer
Re:I'm doubtful (for now). by Drakonian · 2002-12-21 12:26 · Score: 3, Insightful

People like to complain endlessly about DOS and its quirks. And, yes, it does have quirks. But DOS [is] mature, it works, and its quirks really don't affect day-to-day development in most environments.
Linux does look somewhat better and cleaner than DOS. But there are lots of add-on tools for DOS that will need to get ported (GUIs, servers, word processors, batch files, etc.). Just the retraining required to get people to use it in a multi-user environment is pretty daunting--DOS is used by many people who are not primarily developers, and the switch wouldn't be easy for them.
It's been years since we have had any signficant problems with DOS; it seems to be just ticking along, doing its thing. So, I'm not convinced switching to Linux would be enough an advantage to outweigh the risks and retraining costs associated with it. I think it would take a number of large and very visible open source development projects switching to Linux to give me enough confidence in it to try it.

--
Random is the New Order.

PR for arch by tomlord · 2002-12-21 00:20 · Score: 5, Interesting

I wasn't going to bother, but the previous comment mentioning arch has been modded up to 4, so I'll speak a tiny bit of my peace.

SVN is a huge and complex system that aims, for its 1.0 release, to be just a tiny bit more featureful than CVS. There's quite a large number of bugs. The complexity for repository administrators is pretty high. The developers are willfully postponing consideration of a lot of deep issues in revision control. If you follow the dev list closely ... well, just follow the dev list closely.

arch is a tiny, simple system that aims, for its 1.0 release, to be way more featureful than CVS. Although I don't think its ready for deployment in large-scale situations, early adopters tell me that they enjoy using it. arch, unlike svn, is very well positioned to compete (with just a bit more development) with BitKeeper, ClearCase, and others. arch can do a hell of a lot for the commercial free software world with just a bit of investment.

And, I don't know how you should interpret this, but svn has a handful of paid developers -- arch has none and, in fact, I'm literally days away from homelessness.

Go figure.

Re:PR for arch by srussell · 2002-12-21 01:55 · Score: 5, Interesting

This is really unfortunate, Tom. I'm sorry to hear this.
The reason why we chose Subversion over Arch, and probably a reason why Arch isn't getting as much attention as Subversion is, is because of Arch's dependancy on shell scripts. This removes any incentive for a heterogeneous software development shop to use it.
I can argue the merits of Subversion over Visual Source Safe to my clients, but Arch is a much harder sell.
Good luck on finding employment, by the way!
Re:PR for arch by IamTheRealMike · 2002-12-21 02:46 · Score: 3, Insightful

It'd be good if you could state some specific criticisms and arguments for arch vs subversion. We don't all have time to follow many dev lists closely (I follow several and to do it properly takes time). In particular, considering how different arch is from CVS/SVN, what are the advantages? Subversion may not be perfect, and the need to run Apache 2 scared me off, but it has the advantage that it takes all of 2 minutes to learn it if you have used CVS.
For instance, when I set up my project a few months ago, I did look at other code control systems, but CVS won because everybody had it practically installed by default, and it was good enough. Considering how many different commands there are to do very similar operations in arch, it'd be better for you to give it a proper intro methinks. The Linux Journal article just left me with questions.
Re:PR for arch by Anonymous+Conrad · 2002-12-21 03:25 · Score: 4, Interesting

Is arch better than svn? Don't know. It makes too many assumptions that XYZ posix utility is actually the GNU one. My Solaris box doesn't play along with that, and that's a showstopper for me until I can find a *lot* more time to play.

Are you ever going to make a Win32 version? How?
Re:PR for arch by tomlord · 2002-12-21 10:41 · Score: 4, Insightful

> [arch isn't portable beyond unixen because
> it's largely written in sh]

Just as a small clarification on a technical issue:

1) In some sense, yes, that's an obstacle.

2) It is very portable among solid Posix and nearly-Posix systems. It's not terribly useful as it stands on cygwin because (I've been told) `fork/exec' is very slow on cygwin.

3) Most importantly, though, and a bit unlike SVN, arch is designed to be implemented more than once. It's tiny enough to rewrite (say, in Python or Perl) in just a few man-months. It's based in part on the idea of standardizing repository formats, exchange formats, and so forth. In other words, from the point of view of whether or not to support finishing arch, you have to regard it not just as a particular implementation, but as a collection of standards that are effective, simple, and cheap and easy to (re)implement in many different contexts. It's a bit like designing a cataloging system for libraries -- you think bigger than just one implementation.

(Regarding other comments in this "thread", about "get a job", or "you're just trying to steal funding from svn", etc. Well, those aren't bad advice/concerns/objections to discuss -- but I don't think the blog format really supports that kind of discussion -- so I'm going to let them go without direct reply.)

Re:Sounds good by egghat · 2002-12-21 01:18 · Score: 3, Insightful

That's the main problem for adoption of arch, subversion or Aegis. All of these lack support for NetBeans, Eclipse and the other important IDEs.

I guess the moment one of the next generation version controls systems gets good IDE support will be the break-through for this IMHO needed technology improvement.

Bye egghat.

--
-- "As a human being I claim the right to be widely inconsistent", John Peel

Re:Damn... by Majix · 2002-12-21 06:40 · Score: 3, Interesting

For a start, the CVS command line client is non interactive, which is a pain in the ass if you are using SSH authentication and have to enter your passphrase every time you want to do something.

That's what's ssh-agent is for, you upload your public key to the machine running CVS and the agent running on your machine authenticates you without a password.

cvs -d:pserver:anonymous@cvs.project.sourceforge.net:/ path/to/cvs/root checkout file
Oh wow, yeah, now thats so obvious isn't it?

1. You can get rid of everything up to the "checkout" by putting it in your CVSROOT variable.
2. No subsequent updates/checkins ever need this information again as it's stored in the CVS data in the directory. So it's a one time deal.

Subversion replaces the cryptic CVSROOT with a "normal" url, so you'll be typing something like "svn co http://someserver/repository module".

CVS renaming trick breaks history by Earlybird · 2002-12-22 07:02 · Score: 3, Informative

Maintaining the history of individual files across renames is important. Certainly you could grab the entire cvs log output and jam that into the log message for the added file, but you would still break cvs annotate.

Case in point: Quite often, during code reviews or programming sessions, I come across bugs or bad programming methods that exemplify a certain fundamental lack of experience or understanding on part of the author. Using cvs annotate I can determine exactly who wrote the line(s) in question, discuss the problem with the culprit and, if I do my job right, hopefully ensure that the mistake is not repeated. Without the annotation feature, I would have to ask each team member whether they wrote the code in question. Too often it happens that they don't remember. We have had some major directory reorganization the last few months, and at one point all of our files lost their history simply because of a single directory renaming operation.

The remove/add renaming trick damages the projects' collective memory. You end up with bits of the past that are simply missing.

39 of 159 comments (clear)