[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Problems with Limitations or "Differences" of Subversion

From: Eric <spamsink_at_scoot.netis.com>
Date: 2006-11-07 02:35:07 CET

I had a rather, uh, spirited discussion with one of my business partners
today about version control systems in general and Subversion in particular.

We have more or less settled on Subversion to handle version control for
all of our documents ... company policy / procedure documents, meeting
agendas and minutes, project specifications, that sort of thing ... in
addition to source code for projects.

And, therein lies at least part of the problem ... there are two aspects of
Subversion's operation that are causing us many problems ... one of which I
can live with (and defend the operation of Subversion in the face of
arguments from my partners) and the other of which I'm not sure that I can.

As we see it, the two main limitations of Subversion are the inability to
check out and check in individual files (you have to do whole directories),
and the fact that the version number for the whole repository increments
whenever you make any change to any one file.

I really can't defend the second issue .. it just seems to me like a wrong
design decision and I can't think of a reason why it's good or why it happened.

But, as for the first, I got to thinking after my partner left to go home
... If you consider that Subversion is primarily for source code control,
then I guess it makes sense to force the checking out of a whole directory
rather than a single file. After all, if you follow the rule that your
code should at least build before you check it in, how can you build it if
you don't have all the rest of the files?

There is a school of thought that says that it is A Very Bad Idea for
programmers to keep local copies of files (after all, what the %%#$ is
version control for??) and that they should, I suppose, strip off all old
copies of the source every time they check something in. I don't buy into
that and it seems the designers of Subversion didn't either ... you keep a
local work copy of the source files, and you update them whenever necessary
with the latest versions from the version-controlled source tree, right?

That works OK for source file sets where each file is related to the
rest. It works a LOT less well in the case of directory trees full of
documents that are related to one another only because they're part of the
same project or part of the collection of policies and procedures for the
same company. If I make a change to the SRS, I don't want the SDD's
version number to bump.

I'm beginning to think we'd be better off using Subversion for source code
control and something else for document control, though it seems
unfortunate that we would have to do that and not use the same tool for both.

How do you all handle this within your companies or projects?

Eric

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Nov 7 02:36:40 2006

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.