Tim--
Thanks for the reply.
> If you want to check out a single file 'because there's no local copy', that
> probably means that you have somewhere a directory full of local copies of
> files which are all in the same directory on the server.
> What it means in subversion terms, is that you actually checked out this
> directory, and all files in it. Then there are no missing files in your
> local directory. If a new file is added on the host, and you need it, then
> you do an 'svn up' to update with latest changes.
> This way there is no need to check out individual files before you can work
> on them.
Umm... I understand *how* Subversion works. The problem is trying to
make Subversion checkouts work with an already well-established model
for the interaction of build tools and (other) source code management
system. Just saying, "There is no need," ignores certain tough end
cases that I, as a build tool designer, must think through and figure
out how to handle so that, at a minimum, the tool doesn't cause any
damage.
So I'm not saying that Subversion's model should change, or that I don't
understand it. I'm asking for help figuring out a set of rules that
work well to: 1) satisfy Subversion's requirements; 2) fulfill (most
of) people's expectations about the interaction between build tools and
source code management systems; 3) not cause any damage; 4) not leave
people scratching their heads over how to fix a problem when it occurs.
For example, there may be a single local file because the user didn't
check out the directory ahead of time, but plopped in a file that
someone else sent as a patch. Maybe the user even edited it before
running the build. If the build tool were to then come along,
automatically check out the whole directory, and thereby destroy their
work, well, that's clearly Not Good. Being able to wag your finger and
say, "You didn't follow the rules...," in that situation isn't helpful.
(This is just an example; it looks to me like Subversion at least avoids
this sort of extreme problem. When I try to check out a directory that
already has a file in it, I get an "svn: timestamps_equal_p: `foo.in'
not under revision control" error, although I've gotten other messages,
too, depending on what my tree looks like... The point is that if the
tool is going to serve users well, it pays to think through and make
conscious decisions about how to handle these oddball cases, not just
ignore them.)
Based on my continued experimentation with Subversion, here's the
algorithm I'm leaning towards (although this will be tricky to
implement):
-- If I detect that a file is needed and there's no directory,
or the directory is completely empty, checkout the directory
with "svn co -N".
-- If I detect that a file is needed and there's already a .svn in
the directory, then update the directory with "svn up -N".
-- If I detect that a file is needed, and there is no .svn in the
directory, but there are other files in the directory, then
don't do anything (probably with an accompanying warning).
Does that sound like it would cover what users might expect of a build
tool automatically checking out things from Subversion?
--SK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sun Mar 23 21:20:13 2003