[fossil-users] fossil rm followed by unix rm followed by update and files come back, is this desirable?

[Matt Welland]

If I do:

fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
 
then some/file.txt is resurrected which is really really annoying when you just got your build to work and then because files that shouldn't be there suddenly reappear and things break.

I can see where might be some controversy in the behavior of fossil update in this situation. Is there a good practice that avoids the hassle from the files coming back? I've been telling folks to update often to stay in sync and in this case that can cause annoyance and time wasting.

The one possible methodology I can see is to use stash but it seems both overly complicated and actually this behavior seems to violate this phrase in the fossil update help "Any uncommitted changes are retained and applied to the new checkout." :

fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil stash
fossil update
fossil stash pop

[Dmitry Chestnykh]

On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:

> If I do:
>
> fossil rm some/file.txt
> rm some/file.txt

fossil commit

--
Dmitry Chestnykh
http://www.codingrobots.org
_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[Matt Welland]

On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh <dmi...@codingrobots.com> wrote:

On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:

> If I do:
>
> fossil rm some/file.txt
> rm some/file.txt

fossil commit

People often prefer to commit when their work has reached some level of completion or readiness and partially done commits can cause unnecessary breakage for other developers. At the same time staying up to date with incoming changes is often a requirement.
 

[Mike Meyer]

On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland <esti...@gmail.com> wrote:
> On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh <dmi...@codingrobots.com>
> wrote:
>> On Fri, 3 Feb 2012 09:18:32 -0700 Matt Welland wrote:
>> > If I do:
>> > fossil rm some/file.txt
>> > rm some/file.txt
>> fossil commit
> People often prefer to commit when their work has reached some level of
> completion or readiness and partially done commits can cause unnecessary
> breakage for other developers. At the same time staying up to date with
> incoming changes is often a requirement.

Anything that takes so long you have to update between ready/completed
states takes long enough you really ought not to be working without a
net, uh, SCM.

Either work on a branch and merge, or disable autosync, work locally
and pull. Then merge back (or push) when it's ready and updated.

<mike

[Tomek Kott]

I think part of the original post was whether the documentation was correct. i.e., it says uncommitted changes are retained. I would argue that "fossil rm" is an uncommitted change, which should be retained. Either the documentation is wrong or there is a bug w.r.t. "fossil rm".

As a work around, you could try using '-n' to do a dry run, and see if there is actually anything to update.

Tomek

[Richard Hipp]

On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland <esti...@gmail.com> wrote:

If I do:

fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil update
 
then some/file.txt is resurrected which is really really annoying when you just got your build to work and then because files that shouldn't be there suddenly reappear and things break.

I consider this a really obscure corner case.  In 4.5 years of using Fossil intensively, this has never come up for me, that I recall.

Furthermore, a fix will be tricky, since the code in question has to take into account things such as symbolic links to files that have been removed, files that have been renamed rather than deleted,  files for which you have done "fossil rm" but not "rm", files for which you have done "rm" but not "fossil rm", and so forth, and so on.  There is a minefield of potential new and more serious bugs lurking here.  One must move cautiously.

I'll see what I can do.  But honestly, this needs to be a low-priority issue.
 

I can see where might be some controversy in the behavior of fossil update in this situation. Is there a good practice that avoids the hassle from the files coming back? I've been telling folks to update often to stay in sync and in this case that can cause annoyance and time wasting.

The one possible methodology I can see is to use stash but it seems both overly complicated and actually this behavior seems to violate this phrase in the fossil update help "Any uncommitted changes are retained and applied to the new checkout." :

fossil rm some/file.txt
rm some/file.txt
...do stuff...
fossil stash
fossil update
fossil stash pop

_______________________________________________
fossil-users mailing list
fossil...@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

--
D. Richard Hipp
d...@sqlite.org

[Dmitry Chestnykh]

On Fri, 3 Feb 2012 09:57:47 -0700 Matt Welland wrote:

> > > If I do:
> > >
> > > fossil rm some/file.txt
> > > rm some/file.txt
> >
> > fossil commit
> >
>
> People often prefer to commit when their work has reached some level
> of completion or readiness and partially done commits can cause
> unnecessary breakage for other developers. At the same time staying
> up to date with incoming changes is often a requirement.

Ah, I see what you mean. I thought you forgot to commit before
updating. Sorry for misunderstanding.

--
Dmitry Chestnykh
http://www.codingrobots.com