One comment in advance:
I think as result of the discussion in this mailing list,
we already know the right solution:
If the subversion client cannot delete a directory
in the wc because of unversioned files, then
a) subversion gives an warning instead of an error, and
b) the old directory is renamed out of the way,
because the directory may be replaced by a new directory
having the same same.
This solution easily and naturally solves the problem.
**** @Derrick:
Now some comments to your mail:
Agreed, well-designed make systems compiling into separate
directory solves the problem.
Our build-system for our own sources does it in this way.
But in our case this does not help:
The relevant files are part of an contribution directory
which we never compile using our make system.
And of course we want to consider such contributions
as black-box instead of trying to understand it and
add special cleanup scripts.
Besides our case, I see a general problem with
your proposal: Our world is no perfect.
For example, many real-world build systems under linux
compile into the source directories (what are the
conventions for the Linux sources themself? I don't know).
I think it would be a good idea if subversions also works
fine with such real-world projects instead of saying
"you must design your project in a svn-compatible way
to avoid problems." This would be simply not possible
for many projects.
In addition, there is a third problem:
When the directory is not removed, but replaced,
then the temporary files must be removed BEFORE
the svn update to avoid the svn error.
But the smartest make system cannot know which
temporary files to delete BEFORE the svn update is executed
(except it is able to look into the future ;-)
But the svn update fails because of the temporary files.
Or do you really want to clean the complete project build,
which unavoidly costs a lot of time to compile again
(smart make systems don't ?
And to emphasis again:
Cleaning the complete project is no option:
In case of typical larger projects where a complete re-compile
needs hours, this would mean that all developers of the project
are blocked for hours!! Our managers immediately would forbit
subversion if we explain them that the rebuild
is "because of subversion"...
Therefore:
I don't see a way how the problem can be solved outside svn.
Cheers,
Folker
> From: Derrick 'dman' Hudson <dman@dman13.dyndns.org>
> Date: Fri, 19 Dec 2003 13:07:11 -0500
> Subject: Accurate problem description (was: Re: Proposal: svn:temporary property)
>
> 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
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Dec 19 20:26:00 2003