[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Should a locally modified, remotely removed file be handled as a conflict in an update? (retry -- with apologies)

From: Peter Mb <mb.peter_at_yahoo.com>
Date: Mon, 14 Jan 2008 22:31:41 +0800 (CST)

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

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.