Personally, I think subversion makes a great code repository and a
lousy document repository.
One reason is the one that doesn't make sense to you: repository
versioning. For a code project, it makes total sense since the
repository exists as a whole. One file doesn't mean squat, but put
all the files in the repository together and they make an application
that does stuff. That isn't true for a document repository.
<generalization>Another factor is that people doing documentation just
don't care about subversion or revision control.</generalization>
The other factor is that the documents you are storing are likely
binary (MS Office, PDF, Framemaker, or something). So your repository
will grow pretty fast with each revision.
For my team and many of the projects that we host, all of our code
goes into subversion and all of our documentation goes into a wiki.
It's easily viewable by anyone on any platform anywhere, it's version
controlled, and it's easily manipulated.
On 11/6/06, Eric <email@example.com> wrote:
> 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?
> To unsubscribe, e-mail: firstname.lastname@example.org
> For additional commands, e-mail: email@example.com
"Blessed is he who finds happiness in his own foolishness, for he will
always be happy."
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Tue Nov 7 07:05:59 2006