Re: [fossil-users] fossil rm --hard dir1

2017-12-13 Thread Warren Young 
On Dec 13, 2017, at 2:21 PM, Zakero  wrote:
> 
> The "fossil clean" command has the "--emptydirs" option.  That might be 
> useful for the "rm" command as well.

If Fossil got that option, I’d probably forget that it existed a week after the 
change went in.  I’d end up saying something like

$ find . -type d -delete

instead.

One of the core issues here is the difficulty in making Fossil replicate POSIX 
semantics exactly, because they’re fairly complicated.  The same problem 
plagues the symlink implementation, or at least did until recently.  (I’m 
unsure, having not exercised it since the recent redesign.)

If Fossil had a mkdir command, I’d expect it to have an rmdir command to go 
with it, and then I’d *still* not expect rm to remove directories.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm --hard dir1

2017-12-13 Thread Zakero 
On Wed, Dec 13, 2017 at 3:01 PM, Warren Young  wrote:

> On Dec 13, 2017, at 1:03 PM, jungle Boogie 
> wrote:
> >
> > On 13 December 2017 at 07:58, Warren Young  wrote:
> >
> >> I’d feel differently if Fossil owned the directories, but it doesn’t.
> They’re mine; leave them alone!
> >
> > Yes, I agree. I think this topic has been raised here in the past,
> > although that was about removing files.
>
> The thing is, I’m an advocate of
>
> $ ./configure --with-legacy-mv-rm
> $ fossil all set mv-rm-files 1
>
> That is, I want Fossil mv and rm to behave like Unix mv and rm, yet I
> still do not want Fossil touching my directories, because I know I didn’t
> give ownership of them to Fossil.  That might just be a training issue.
>
> One of the top-level directories in a Fossil based project I was looking
> at recently has a top-level directory that holds both versioned content and
> generated content.  If I removed that directory with Fossil, I’d expect the
> generated content to be left behind, even with --hard.


What about the case where Fossil owns all the files in dir/sub-dir/?
Should "fossil rm --hard dir/" remove the "sub-dir" directory since after
the file remove operation the "sub-dir" will be empty?

The "fossil clean" command has the "--emptydirs" option.  That might be
useful for the "rm" command as well.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm --hard dir1

2017-12-13 Thread Warren Young 
On Dec 13, 2017, at 1:03 PM, jungle Boogie  wrote:
> 
> On 13 December 2017 at 07:58, Warren Young  wrote:
> 
>> I’d feel differently if Fossil owned the directories, but it doesn’t.  
>> They’re mine; leave them alone!
> 
> Yes, I agree. I think this topic has been raised here in the past,
> although that was about removing files.

The thing is, I’m an advocate of 

$ ./configure --with-legacy-mv-rm
$ fossil all set mv-rm-files 1

That is, I want Fossil mv and rm to behave like Unix mv and rm, yet I still do 
not want Fossil touching my directories, because I know I didn’t give ownership 
of them to Fossil.  That might just be a training issue.

One of the top-level directories in a Fossil based project I was looking at 
recently has a top-level directory that holds both versioned content and 
generated content.  If I removed that directory with Fossil, I’d expect the 
generated content to be left behind, even with --hard.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm --hard dir1

2017-12-13 Thread jungle Boogie 
On 13 December 2017 at 07:58, Warren Young  wrote:

> I’d feel differently if Fossil owned the directories, but it doesn’t.  
> They’re mine; leave them alone!

Yes, I agree. I think this topic has been raised here in the past,
although that was about removing files. Still, If I created the
directory, I don't want fossil to remove it (even though it would save
me extra typing).
https://en.wikipedia.org/wiki/Principle_of_least_astonishment

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm --hard dir1

2017-12-13 Thread Warren Young 
On Dec 13, 2017, at 6:21 AM, Tino Lange  wrote:
> 
> The directory/directories will keep existing!

Given that Fossil doesn’t know anything about directories, other than as 
containers for the files it manages, I’m not sure that isn’t the right thing.

To have Fossil remove intermediate directories means it is expected to remove 
things it doesn’t own.

Also, what happens if the directory isn’t empty, or if all the user wants is to 
clear the Fossil-managed files out of the directory but leave the directory 
structure intact?

I’d feel differently if Fossil owned the directories, but it doesn’t.  They’re 
mine; leave them alone!
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil rm --hard dir1

2017-12-13 Thread Tino Lange 
Hi!

When doing a 
$ fossil rm --hard dir1

it will unregister from fossil and then delete all files within the 
'dir1' hierarchy.

But: The directory/directories will keep existing!

I need to do a
$ rm -rf dir1
afterwards (so the whole --hard is mostly needless, since I need to do 
the additional "rm" anyhow).

Could this be fixed, please? At least in this usage scenario above one 
wants to have no 'dir1' after the fossil operation, or?

Thanks and best regards

Tino

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

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

2012-02-04 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

2012-02-03 Thread 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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

2012-02-03 Thread 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-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

2012-02-03 Thread Matt Welland 
On Fri, Feb 3, 2012 at 9:46 AM, Dmitry Chestnykh dmi...@codingrobots.comwrote:

 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.


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

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

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

2012-02-03 Thread Mike Meyer 
On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@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
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

2012-02-03 Thread 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

On Fri, Feb 3, 2012 at 12:06 PM, Mike Meyer m...@mired.org wrote:

 On Fri, Feb 3, 2012 at 10:57 AM, Matt Welland estifo...@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
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

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

2012-02-03 Thread Richard Hipp 
On Fri, Feb 3, 2012 at 11:18 AM, Matt Welland estifo...@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-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm ./*

2010-06-24 Thread Richard Hipp 
On Thu, Jun 24, 2010 at 10:37 AM, Kohn Bernhard bernhard.k...@ait.ac.atwrote:

  Hello all,



 I have experienced following behavior when removing files.



 I open a repository. I would like to delete all files, so I use

 fossil rm ./*

 In the output of the commandline the filenames (also with subdirectories)
 with DELETED in front appeared.

 When I try to commit the deleted files with

 fossil commit –m “remove all files”

 I get a response : nothing to commit



 I can only remove files out of the repository per typing every single file.
 Is this an expected behavior?

Try this:

fossil rm `fossil ls`

Removing all the files from a repository seems to me to be a obscure corner
case (in 35 years of programming, it is not something that I've ever wanted
to do before - why not just start a new project?)  So it seems to me that
leveraging the unix shell to get the job done, as shown above is not an
especially onerous task.  Adding support for wildcards on fossil rm is not
a priority.




 Best regards

   Bernhard



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




-- 
-
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil rm ./*

2010-06-24 Thread Kohn Bernhard 
Oh no, I didn't meant to say, its important.
And yes, you are right, I use this for an obscure corner case, and doing this 
with commandline is no problem.


Best regards
  Bernhard
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users