Re: [OT] Re: Subversion revision controll system
Re: [OT] Re: Subversion revision controll system
- Subject: Re: [OT] Re: Subversion revision controll system
- From: Chris Hanson <email@hidden>
- Date: Sun, 25 May 2003 16:29:09 -0400
On Saturday, May 24, 2003, at 04:25 AM, Alastair J.Houghton wrote:
No, it shouldn't. Subversion and CVS are *scalable*, in a way that
VCSs that have the server remember the client workspace state cannot
be; this is very important for the Free Software community because the
version control systems need to be accessible to *everyone* over the
Internet.
Perforce is also reasonably scalable. There are companies using
Perforce with thousands of developers hitting one repository. I hear
you about needing thousands of developers to be able to anonymously hit
a repository without a huge cost; my second idea would enable that.
It wouldn't be a good idea to let you change the directory name
either, because it lets tools that do understand CVS or Subversion
work easily with your working copy.
This is isomorphic to understanding CVS or Subversion. If Subversion
created a master ~/.svn/ directory under which it stored information
about all the repositories it was tracking, any tool that integrated
with Subversion would *know* to check this information. It would know
to check your hypothetical ~/.svnrc file to find the location of this
workspace-tracking directory. And so on.
The difference is that tools that *don't* natively support Subversion
would not get confused by the presence of .svn directories.
Third-party tools shouldn't be randomly traversing your source tree
:-) If they do traverse your source tree, then they should have
options to exclude files and directories; since you know which VCS you
are using for your project, it's easy to tell other tools which
files/directories to ignore.
It's not just a matter of source trees. It's a matter of
*repositories*. Many people track *all* project materials through
their software configuration management system; that's why they're
properly called "software configuration management" systems rather than
"revision control" systems. This includes things like architecture
documentation, sets of user story, help folders, build scripts,
packaging art, everything that goes into a release of the software is
versioned and tracked and managed in *one place*.
EOModeler is a good example. A file created by EOModeler is actually
an eomodeld package. Apple had to modify EOModeler to work properly
with CVS because previously, it would just create a new eomodeld and
rename it to the name of the old one. This would not preserve the CVS
repository information in the "file."
*Apple should not have had to modify anything.* It's the SCM system's
responsibility to work with the rest of your tools, not the tools'
responsibility to work with the SCM system. Particularly when every
SCM system works slightly differently and leaves different droppings
all over the place that need to be dealt with.
The simple situation is to store the repository information in a
standard place that *isn't* in the source tree. That way everybody
wins, with a minimum of headaches.
-- Chris
--
Chris Hanson, bDistributed.com, Inc. | Email: email@hidden
Custom Application Development | Phone: +1-847-372-3955
http://bdistributed.com/ | Fax: +1-847-589-3738
http://bdistributed.com/Articles/ | Personal Email: email@hidden
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.