On Thu, 18 Dec 2003 12:28:17 -0500, Francois Beausoleil wrote:
> On Thu, 18 Dec 2003 18:23:00 +0100, "Folker Schamel"
>> > The pretty easy workaround for user B is to do:
>> >
>> > $ make clean
>> > $ svn up
>> > $ make
>> >
>> > That should be too hard to get used to.
This certainly solves the problem. (The problem is identified below.)
>> It still is only a workaround for several reasons.
>>
>> First, it does not work for all make systems.
>> In addition, there are other kind of temporary files.
>> (For example, we had the problem with pyc python files,
>> where your workaround does not work.
Sure it does. In your Makefile (or SConstruct, or build.xml or
whatever you are using) do
find src -name \*.pyc | xargs rm
(or equivalent).
>> In addition, our software generates many different
>> kind of temporary files where there exists
>> no clear command.)
>>
>> Second, a complete re-build often cost a lot of time;
>> in our case it would cost several hours.
These are issues with designing the build system properly.
> I wouldn't want to crash the party, but can't the files be generated in
> another folder ?
>
> For instance, in my Java projects, I have a src/ folder, and a build/
> folder. My top-level project folder (trunk/ in most cases) has
> svn:ignore set to "build tmp". This solves the problem rather nicely,
> for me.
Bingo! The original problem is that source and generated files are
residing in the same directory.
The problem is not directly related to svn, but rather with poor
interaction between users and tools (and tools aren't omniscient, not
knowing what the user really desires). IMO versioned directories
should not contain any unversioned files. The only exception is if
the unversioned files are unimportant -and- the user is aware of the
potential conflict caused by lack of knowledge on the part of the VCS.
The first solution to this issue is to separate the generated files
from the source files. By doing this, svn will never see generated
files and can't possibly have any issue with them. Since generated
files are generated, not versioned, this is a good idea. It is the
responsibility of the build system to ensure that generated files are
generated (or moved to, post-generation) in the right location.
The other solution, given above, is to clean out all the generated
files. The projects where I work use both of these techniques -- a
separate "build" directory which is blown away at each build. Our
projects are such that rebuilding the whole thing takes little time,
certainly much less than the time that would be lost tracking down
broken-dependency related failure to compile changes or leftover
generated files. Admittedly, for some projects building the system is
too expensive to perform frequently.
It would be nice if a system could know what generated files to delete
when the corresponding source files are deleted and if those files
could be deleted immediately. Every build and version control system
I've encounted has the issue of not knowing precisely when to remove
generated files, for example if the corresponding source file is
removed. The problem seems to be rooted in making decisions based
solely on what is and not taking into account what isn't. I think the
desired behavior would require an integrated SCM system, not a
loosely-coupled VCS and system-level file manipulation. (ie you'd
need to explictly tell the system what generated files go with what
source files, and you'd need to tell the system to delete the source
files rather than using 'rm' or equivalent)
-D
--
The Lord detests all the proud of heart.
Be sure of this: They will not go unpunished.
Proverbs 16:7
www: http://dman13.dyndns.org/~dman/ jabber: dman_at_dman13.dyndns.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 19 19:09:05 2003