Subversion: Not Impossible, and Tall Buildings
Most buildings have one common design aspect: the exit is usually on the ground floor, and it is accessible by using the elevators or the stairs. But exiting a building that way is inconvenient if I want to leave a building Right Now, without delay. Achieving this is not impossible: I can simply jump out a window. Does that sound foolish? It all depends on the context.
If I’m on the fifth floor and I want to leave casually — as is usually the case, under normal circumstances of everyday life — jumping out of the window makes no sense at all, even though it’s not impossible to do so. The building, and my body, weren’t designed for this, making it too risky. However, under special circumstances which deviate from the norm — for instance, if the building is on fire — then jumping from the fifth floor may make perfect sense. But that’s an exceptional case, certainly not part of the regular process of exiting a building.
What does all this have to do with Subversion?
After reading Mike’s blog about Parallel IP approvals for incubating projects, I could see one problem coming at me from a mile away (roughly 1.6 km). With Parallel IP Approval (PIPA?), projects in incubation are authorized to put code into CVS that has not yet been approved. I can only speculate that regular requests to remove code (either because it’s not approved, or because it’s no longer required) will be triggered as a result. Although Mike’s blog only mentions CVS, many Incubating projects may prefer to use SVN instead of CVS, and that’s where the problem begins: SVN isn’t designed for deleting files or directories permanently, without leaving a history. This is a non-issue for CVS, however, and one reason why parallel IP using CVS is a Non Issue.
Although not impossible, to delete something from SVN is difficult: one must dump the whole repository to a dump file, edit the dump file to remove the offending records, delete the repository, re-create the repository (empty), and load the dump file in to the repository. Difficult, indeed, but it’s not impossible.
But does it make sense to do so?
It depends on the context. If permanently deleting files from a repository is a normal, expected and somewhat regular occurrence, then I must argue that SVN is simply not the right tool to use. On the other hand, if code was committed accidentally and it must be deleted for legal reasons, then the special circumstance certainly warrants the trouble and hassle of removing it, as it’s an exception, not a rule, to delete files.
So what’s the point of this post? Just because something is Not Impossible doesn’t mean it’s Not An Issue. And for this reason, I’d state that projects in Incubation only be permitted to use CVS — as lame as that may sound — simply because of the way SVN is designed vs. the way we would be expected to use it.
Posted January 26th, 2007 by Denis Roy in category: Uncategorized
You can skip to the end and leave a response. Pinging is currently not allowed.
4 Responses to “Subversion: Not Impossible, and Tall Buildings”
Leave a Reply
You must be logged in using your Eclipse Bugzilla account to post a comment.
Gunnar Says:
January 26th, 2007 at 4:31 pm
I’m not sure if it’s that simple. The project is part of your history … actually … it makes your history together with a lot other great projects and great people.
However, you can get sued later because you intentionally removed evidence in some abstract other case not related to you but to one of the guys committing this stuff. Think about it that way.
Anyway, there are more alternatives, for example, a separate incubation repository for each project. But I agree, no admin will like this, it causes a lot of work. But wait, creating CVS repositories causes work too. Maybe it’s just a matter of the tools and processes the admin uses.
But I agree, allowing projects under incubation with potential unexperienced committers to commit code into the one and only Eclipse repository requires a huge trust, and mistakes can happen, actually, they will, someday.
Nick Says:
January 27th, 2007 at 11:19 am
“But wait, creating CVS repositories causes work too.”
True, but it’s just:
mkdir /cvsroot/technology/$newproject
chown $newperson:$newgroup /cvsroot/technology/$newproject
That’s the sort of admin I can handle - the process described by Denis sounds a lot more like a visit to the dentist: necessary given the right conditions, but entirely avoidable.
Grahame Says:
January 30th, 2007 at 10:15 pm
We were discussing this on the OHF committers call today. We do want to explore using svn, and we are in incubation, and we will be using the parallel IP process, so this is all very relevant to us.
The question for me is whether it’s a problem to have unapproved content in version control archives. Is this really a problem? obviously it would be a problem to have unapproved content in the current snapshot of a project that is not in incubation. But it seems to me that it’s aiming too high to not have unapproved content in the history either.
It’s history, after all, so it can’t be changed. To me, the idea that we need to go and rewrite history when mistakes are made - whether large or small - is inappropriate, and eclipse should simply state that the current snapshot in version control is controlled, and the history may contain inappropriate content - like bugs, really.
Denis Roy Says:
February 4th, 2007 at 3:15 pm
I agree with everything you say, Grahame. I’ll discuss with the folks on the IP team to see if third-party code in CVS/SVN really does need to be removed.