Hi Tim--
> I thought that 'svn st -u' or 'svn st -uv' will give you extensive
> information including stuff that is new / changed on the server. If you do
> this command on the working-copy root before doing anything else, you can
> determine instantly which files are out of date and need to be updated.
Thanks, thats very helpful. I need to think about how I might be able
to use it.
> Really, I think that in the subversion model there is no place for
> single-file checkouts because multiple files are atomically committed: if
> you check in files f1.c and f2.c, that's one unit. That's one change to 2
> files and not 2 changes. Those changes are probably very related and
> probably even dependant on each other. For instance, together they are the
> fix for Issue#17 in your issue-tracker system. Which means that you
> shouldn't check out just file f2.c, because you will be building an
> inconsistent system.
Tim, I *agree* with you. I'm not checking out an individual file from
Subversion. I'm not even going to try to do so. I'm not asking for a
change to the Subversion model.
But the dilemma is that the granularity with which a build tool
*detects* something is missing is file-by-file, while Subversion has
directory granularity designed into it. So the thorny issue is:
Can we marry the file granularity of build-tool detection with the
directory granularity of Subversion in a way that does some
useful work for software developers?
I mean, am I crazy to imagine that if we get creative, we might be able
to invent a useful way to have Subversion and a build tool cooperate to
make life easier for software developers? Based on the education I'm
getting about Subversion, I'm beginning to think so...
> I think also, that you should do 'svn up' on the whole working-copy, not
> just on subdir 'sub' precisely because of what you say - files f1.c and f2.c
> can be used outside of their subdirectories.
I thought about this, but that causes extra work if you really *do* know
that you only want to work on a specific subdirectory--which you might
if you know a specific subsystem is self-contained, for example.
Nevertheless, checking out or updating the whole project might still be
the best middle ground.
> BTW, how would SCons detect that file f2.c is missing from the local
> configuration? There needs to be a reference to file f2.c somewhere in the
> working-copy, and if there's a reference to a file which doesn't exist that
> revision of the repository cannot be built per se. Or does SCons have other
> means?
No, in SCons, a file does need to be mentioned in an SConscript file
somewhere (explicitly or implicitly). What you describe might happen if
I'm integrating an externally-generated patch that contains an updated
SConscript file, for example.
> How, in general, would SCons detect that a file is out-of-date with regards
> to the repository on the server?
The build tool shouldn't try to do that. The existing model (Make) for
this kind of interaction is to only fetch things that don't exist, not
to update everything perfectly every time you build.
> And what would be the use of building a program in a working-copy which is
> only partially up-to-date with the repository? I understand that SCons and
> any similar build-tool wants to minimize the amount of work, hence
> dependancy checking and building f1.c only if it's newer than f1.o etc etc.
> But 'svn up' doesn't transmit the whole repository, only changes. So in a
> way, IMHO at least, doing 'svn up' is no more expensive then it needs to be.
Good point.
> If you build your files, checking out only those which have been changed,
No, checking out only those files (or perhaps directories) that don't
exist.
> and then start your program with a shellscript which has been changed on the
> server but not been updated in your working-copy because SCons hasn't tried
> to build it, has no dependancies pointing to it... your program potentially
> still doesn't run as it should.
> Similar for data- and configurationfiles that your program uses and that
> don't appear in the dependancy-graph of SCons.
Right, the point isn't that it works for every case; you can still shoot
yourself in the foot. There are, however, cases where people find this
sort of model useful because a tool can do things for them that they'd
otherwise have to do by hand.
> I might be missing something here, as I don't know SCons and don't use make
> to check out my files from CVS. You had an example of someone putting a
> number of files somewhere that come from an SVN repository and then later
> checking out the repository on top of those files, wanting to keep the
> versions he put there. What would such a use-case look like?
Well, I'm not sure what the output in a Subversion use case would look
like, because I don't yet have an idea of how (or if) this would even
work.
But suppose that someone sent me a new copy of sub/f1.c to test; here's
what that would look like for SCCS:
$ mkdir sub
$ cp $HOME/new_f1.c sub/f1.c
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -c -o sub/f1.o sub/f1.c
sccs get -e sub/f2.c
sub/f2.c 1.1 -> 1.2: 10 lines
cc -c -o sub/f2.o sub/f2.c
cc -o sub/foo sub/f1.o sub/f2.o
scons: done building targets.
In other words, the combination of build tool + source code management
system has helped me cut down on the amount of stuff I need to do by
hand to test the new copy.
The rub here is that what works well for other source code management
systems is backwards for Subversion, if I understand correctly. The
"right" way to do this with Subversion would be first to checkout the
project (by hand), and then copy the new file into it, right?
So look at the question this way: is there any part of that by-hand use
of Subversion in this scenario that could be handled by a sufficiently
smart build tool, thereby making less work for the user? If so, I'd
think it would be a win all around.
But then again, maybe I'm dreaming...
> Apologies if my message somehow totally misses the point.
No, you've given me a lot of food for thought, and gotten me to
think through and explain what I'm getting at more clearly, which is
definitely a Good Thing. Thanks for the input.
--SK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Mar 25 01:58:27 2003