Hi,
Sorry for my crappy outlook - it doesn't put proper '> ' in front of
original lines (and will mess up other things if I tell it to do so). I'll
put my comments at the top rather than mix them in with the original text.
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.
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.
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.
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?
How, in general, would SCons detect that a file is out-of-date with regards
to the repository on the server?
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.
If you build your files, checking out only those which have been changed,
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.
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?
Apologies if my message somehow totally misses the point.
With regards,
--Tim
-----Original Message-----
From: Steven Knight [mailto:knight@baldmt.com]
Sent: maandag 24 maart 2003 14:57
To: Vladimir Prus
Cc: Leeuw van der, Tim; dev@subversion.tigris.org
Subject: Re: integrating Subversion with a build tool?
Hi Volodya--
Thanks for the reply and suggestion.
> > 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.
>
> I think it would be better if you explain how VC tool interaction is
supposed
> to work in SCons. For example, I can't imagine how per-file checkout can
> be specified/used.
>
> I can easily imagine the build tool integration on project level (i.e.
when
> building Subversion, APR and APR-utils are fetched automatically). OTOH,
> there's 'svn:externals' mechanism which is *very* good for such kind of
thing.
> It allows, when checking out a project, to grab other projects it
requires.
>
> So, can you outline primary use cases which are needed, or point to some
> SCons docs which describe it.
Okay, good idea.
Here's a sample of how I *thought* this might work for a local
Subversion repository. Given the following in an SConstruct file (the
SCons equivalent of a Makefile):
env = Environment()
svn = env.Subversion('file:///usr/Subversion/project')
env.SourceCode('.', svn)
SConscript('sub/SConscript', "env")
env.Program('sub/foo', ['sub/f1.c'])
The "env.SourceCode()" line tells SCons that anything under the current
directory, if it doesn't already exist locally, can probably be found by
checking out (all or part of) the source from the specified Subversion
repository.
Now, I can make SCons check out the directory, not the individual file,
so if for some reason the "sub" subdirectory hasn't already been checked
out, the output from a run with the above configuration might look like:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
svn co -N file:///usr/Subversion/project/sub
A sub/f1.c
A sub/SConscript
Checked out revision 1.
cc -c -o sub/f1.o sub/f1.c
cc -o sub/foo sub/f1.o
scons: done building targets.
But because of the way the walk of the dependency tree is done, SCons
(or, probably, any other build tool) can't realize that the directory
needs to be checked out until it goes to try to build the sub/f1.o
object file and finds out that the sub/f1.c source file isn't there.
Now suppose that after I had checked out the above revision, but before
I built the program, someone has checked in a change that adds a new
sub/f2.c source file. In this case, sub/f1.c would already exist, but
sub/f2.c would not. SCons would detect that sub/f2.c is missing and,
based on the "env.Subversion()" specification in its input file, try to
create sub/f2.c from the Subversion repository. I think the right thing
to do here is detect the sub/.svn directory and issue an update, not a
checkout, in which case I *think* the output would look something like:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
svn up -N file:///usr/Subversion/project/sub
A sub/f2.c
Checked out revision 2.
cc -c -o sub/f2.o sub/f2.c
cc -o sub/foo sub/f1.o sub/f2.o
scons: done building targets.
Am I on track so far?
Now, one side effect of having to update the whole directory is that it
might update something that's already been visited in the dependency
walk. For example, if I'd not yet built anything in that subdirectory,
and in revision 2 someone modified the sub/f1.c file *and* has added
a new sub/f2.c file, then SCons would likely not detect the missing
sub/f2.c file and the need to update until after it had built sub/f1.o.
In the most straightforward implementation, that could cause the
following problem:
$ scons
scons: Reading SConscript files ...
scons: done reading SConscript files.
scons: Building targets ...
cc -c -o sub/f1.o sub/f1.c
svn up -N file:///usr/Subversion/project/sub
U sub/f1.c
A sub/f2.c
Checked out revision 2.
cc -c -o sub/f2.o sub/f2.c
cc -o sub/foo sub/f1.o sub/f2.o
scons: done building targets.
Uh-oh, I'd have now created an incorrect program, because sub/f1.c has
been updated after I've already compiled it. This is where I start to
wonder if Subversion and automatic build tool checkouts just don't work
well together and I should drop trying to support Subversion.
Another way I might solve the above problem would be to create a
dependency on the directory as well as the source file. This would try
to make sure that no source file from a directory gets used before *all*
the source files in a directory are present, so I could issue the "svn
co" or "svn up" before anything depending on them gets built. But this
could be really tricky, because a source file in one subdirectory could
be used anywhere in the tree, not just local to that subdirectory.
It's cases like this that are making me turn to the Subversion community
to find out if I'm overlooking some clever way of dealing with
Subversion that might make this doable. But I'm beginning to wonder if
this really is a case of a square peg meeting a round hole...?
--SK
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Mar 24 15:45:14 2003