When resolving using "mine", I think the file's status should become "added". The file, or better put, file with the same name and location, has actually been deleted once, albeit for a short while, and a file with the same name, location has actuaaly been added. Fits best the actual history of the file, I think.
Anybody having other thoughts on this. I'm tempted to submit this one as a bug/issue.
Reagrds,
Peter
P.S. I haven't given much thought to the locally renamed directory scenario.Rename all files in the dir to .mine??
----- Original Message ----
> From: Dave Lawrence <dlawrence_at_ad-holdings.co.uk>
> To: users_at_subversion.tigris.org
> Sent: Tuesday, January 8, 2008 2:49:02 PM
> Subject: Re: Should a locally modified, remotely removed file be handled as a conflict in an update? (retry -- with apologies)
>
> Peter Mb wrote:
> > [Despite having plain text messages configured in my
> preferences,
>
somehow some javascript found its way in my previous message.
> Apologies.
>
I'll try again, hopefully things will go right this time.]
> >
> > Hello all,
> >
> >
> > Recently I noticed that when one has modified a file locally and
> does
>
an update when someone else has removed or moved the file to
> another
>
directory and commited, the locally modified file is no longer marked
> is
>
being under svn control but keeps its original filename.
> >
> The same is true for directories that contain modified or
> unversioned
>
items.
>
> >
> > This may lead to several problems:
> >
> > - A file may have become obsolete due to a refactoring by
> one
>
developer. This developer removes the file and commits. A second
> developer
>
concurrently adds fucncionallity to the file as part of
> another
>
refactoring. When the latter does an update there are conflicting
> refactorings.
>
The deleted file is not marked as being a part of the conflict, but
> it
>
surely is.
> >
> > - The file is moved remotely, the developer that has a modified
> copy
>
locally does an update. The subsequent local build fails because
> of
>
doubly defined symbols.
> >
> > - A developer removes a file by accident, commits, another
> developer
>
does an update, having the removed file modified. The local
> build
>
succeeds. That the repository is in a non-buildable state goes
> unnoticed
>
longer than it should.
> >
> > Note that even trivial changes,.added white space, an added
> debugging
>
statement, for instance, leads to the last two problems.
> >
> >
> > My suggestion would be, at he very least, to rename the
> remotely
>
removed file to .mine, similar to what a failed merge does.
> This
>
way, the conflict stands out and the file no longer takes part in
> the
>
build.
> >
> >
> > Any thoughts on this, please?
>
> I agree. Although what happens when you resolve the conflict, suppose
> you resolve using "mine", does the file's status become added /
> replaced? Presumably if you resolve using "theirs" then the file is
> deleted, but there must be also a third option to "keep" the file
> unversioned.
>
> If not a conflict then I think there should at least be a warning when
> this happens. The closest thing I've seen to a warning about this
> situation is that if a file is locally modified and remotely deleted,
> TortoiseSVN will report status info about it in red (which is
> the
>
colour
> they use for conflicts).
>
> Then there is the question of how to handle directories, presumably
> the
>
> same can be done? I'm not sure about the renaming to .mine though...
>
> >
> >
> > Regards,
> > Peter
> >
> >
> >
> >
> >
> >
>
_______________________________________________________________________________
> _____
> > Be a better friend, newshound, and
> > know-it-all with Yahoo! Mobile. Try it
> now.
>
http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
> For additional commands, e-mail: users-help_at_subversion.tigris.org
>
>
____________________________________________________________________________________
Never miss a thing. Make Yahoo your home page.
http://www.yahoo.com/r/hs
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: users-help_at_subversion.tigris.org
Received on 2008-01-14 15:32:05 CET