Since it seems that I didn't describe the problem
clear enough, I try it more in detail:
The repository revision 100 includes the following files
(plus others):
fancy_module/subdir/doit.c
fancy_module/subdir/Makefile
other_module/main/doit.c
other_module/main/Makefile
Makefile
The root Makefile calls both fancy_module/subdir/Makefile
and other_module/main/Makefile.
This generates the following files:
fancy_module/subdir/doit.obj
other_module/main/doit.obj
on all working copies.
The project has this structure for a long time.
Now, some day, user A working on fancy_module decides that
fancy_module/subdir is not needed anymore.
He deletes fancy_module/subdir/doit.obj,
and he svn-deletes fancy_module/subdir.
And of course, he adjusts the global Makefile
to not call fancy_module/subdir/Makefile anymore.
Everything compiles again, and he commits.
User B never has looked into fancy_module;
User B makes an update as every day, and will get the error
that "fancy_module/subdir" cannot be deleted,
because there is "fancy_module/subdir/doit.obj".
But he has never heard about this module, directory or file.
The clean solution is that when fancy_module/subdir/
was created the first time, instead of setting
"svn:ignore *.obj", you set "svn:temporary *.obj".
This makes sense because user A (not user B)
is working on this module and therefore understands
that these files are temorary.
By this, if user B updates the revision where
fancy_module/subdir/ was deleted again,
then subversion silently deletes
fancy_module/subdir/doit.obj.
As consequence, user B can make an update as usual
without problems, and can compile as usual
without problems.
Do you now understand what I mean?
The problem is that such situations are not rare;
this problem will come up basically every time
when you make a structural change to your project;
and structural changes happen for large projects
(this is the reason by svn has better move / copy / delete
support than svs).
Furthermore, for larger projects, there is not only
one user B, but many users B.
Cheers,
Folker
John Peacock wrote:
> Folker Schamel wrote:
>
>> User A is working on a module fancy_module.
>> Some day, user A decides to remove fancy_module/subdir.
>
>
> This is the cause of the problem, not anything User B has any control
> over. User A has broken the compilation for User B's module.
>
>>
>> User B works on the same project but on different modules.
>> User B is even not aware of the existance of fancy_module/subdir.
>> But user B indirectly compiles fancy_module/subdir by executing
>> a project make, creating temporary files in fancy_module/subdir.
>> But now when user B does his regulary update,
>> he will suddenly get an error about modified files in
>> fancy_module/subdir, a directory, he has never heared about.
>
>
> If User B had done an update before compiling, the fancy_module/subdir
> would have been removed from the WC and the compilation would fail for
> those reasons. Still not subversion's fault; the module dependencies
> need to be fixed so that User A cannot bork User B's modules.
>
> I don't see how a new property would help this in the slightest. It may
> be that fancy_module/subdir never should have been in the repository in
> the first place, in which case my original comment stands.
>
> John
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Dec 18 16:56:27 2003