*** Problem description:
During svn update, replacing a directory containing orphaned
files generates an error, because subversion cannot delete
the old directory and therefore cannot create a new
directory having the same name.
A weaker variant of the problem is to delete a directory
(not replace a directory). Currenly subversion also
generates an error because it cannot delete the directory.
*** Possibilities of avoiding the problem?
As correctly pointed out by several people, a good make
system / directory structure avoids mixing of versioned
and temporary files within the same directory
(our make system works in this way, too).
Then there is no problem in such cases.
However, sometimes this is not possible.
Some existing projects simply use a make system compiling
into the source directories, and this cannot be changed.
Other projects also have different kind of temporary files,
which cannot easily be put into separate folders
(e.g. python pyc files).
Other projects (like ours) have modules in a contribution
directory, which are not "controlled" by the users,
but should be treated as black boxes for good reasons.
Another argument was to not replace directories.
Well, sometimes this cannot be avoided, because for some
technical (or design) reason the directory MUST
have the same name.
In addition, a directory may be deleted and then
added again after some time; for a user which didn't
update in the meanwile, the svn update basically
tries to perform a replace.
Some people suggested to delete the orhpaned files
manually; however, at least under windows this
is very inconvinient (or must be done manually?).
To simply delete the whole directory including its
.svn directories also looks more like a ugly hack.
Therefore, I think there are situations where the
project structure cannot be designed or changed in such
way that the problem is avoided in a practical way.
At least in our case I don't know how we could
have avoided this situation in a practical way.
*** My current proposal:
a) The svn update error message is changed
into a warning. (This is enough to solve
the weak variant of the problem).
In addition, the message is enhanced
to suggest using the new option
--move-away to solve the problem.
b) svn update gets a new option --move-away.
If enabled, directories which cannot be deleted
but are in the way are renamed to something
like directory.old .
(Idea: This option also could rename files which are
in the way, avoiding the is-in-the-way error at all).
***
Any comments?
Or am I really the only person on the world thinking
that there is a problem which should be solved?
(If no-one has the feeling, too, that there is a problem
then of course I agree that nothing should be changed...)
In the case that I've overseen something
(e.g. someone posted a technique how this problem
can be avoided), forgive me and tell me again. Thanks!
Cheers,
Folker
Branko Čibej wrote:
> Folker Schamel wrote:
>
>
>>>>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.
>>>
>>>
>>>
>>>Right. And "svn status" will tell him that that directory is no longer
>>>under version control. Whereupon he will delete it, update again, and
>>>the problem will go away.
>>
>>
>>I think the philosophy of subversion should be that
>>if user A and user B work on disjunct project parts,
>>they should not interfer with each other,
>>i.e. user B is not bothered by changes of user A or vice versa.
>>svn:temporary would archive this.
>
>
> No. What you've been describing is a consequence of a feature of the
> build system. In the same situation, every version control system that I
> know of (and that does directory versioning) will behave analogously to
> Subversion.
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Sat Dec 20 02:57:36 2003