Re: [fossil-users] Justification for two-step mv and rm

2015-03-09 23:06 GMT+01:00 Tontyna : > Hurray and thank you! > > Will `addremove` become `addforget`? (Sorry, couldn't resist nitpicking.) It should be 'addforgetrename', with the added functionality that renames are detected too ;-) Regards, Jan Nijtmans _

Re: [fossil-users] Justification for two-step mv and rm

Am 09.03.2015 um 10:09 schrieb Jan Nijtmans: Done now: This means that whatever happens with "fossil rm|mv|delete", the "fossil rename" and "fossil forget" will continue to function as they do now. Hurray and thank you! Will

Re: [fossil-users] Justification for two-step mv and rm

2015-03-06 16:58 GMT+01:00 Jan Danielsson : > On 06/03/15 15:10, Jan Nijtmans wrote: >> Any objections against adding "fossil forget" as alias >> to "fossil rm" If not, I'll be glad to add it, awaiting >> further discussion. > >No objection. I'm even going to go so far as to say I'll be c

Re: [fossil-users] Justification for two-step mv and rm

On Fri, Mar 06, 2015 at 03:46:08PM +0100, j. van den hoff wrote: > On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna wrote: Hi there, > >I'd prefer that default `rm`/`mv` without options leave my file > >system alone. A `--forcefilesytem` flag would be a convenient > >enhancement. > > personally, I w

Re: [fossil-users] Justification for two-step mv and rm

Am 06.03.2015 um 18:45 schrieb Ron W: On Fri, Mar 6, 2015 at 9:11 AM, Tontyna mailto:tont...@ultrareal.de>> wrote: Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete f

Re: [fossil-users] Justification for two-step mv and rm

On Fri, Mar 6, 2015 at 9:11 AM, Tontyna wrote: > Maybe me and my co-workers aren't exemplars of The Average Fossil User > (current and future) but typing commands in a shell is not our common > approach to move or delete files. > Reference point are files on a harddrive actually belonging to a sp

Re: [fossil-users] Justification for two-step mv and rm

On 06/03/15 15:10, Jan Nijtmans wrote: [---] > "fossil rename" already exists as alias to "fossil mv", so I > suggest to add "fossil forget" as alias to "fossil rm". Then > later the behavior of fossil rm/mv" can be modified, while > forget/rename will continue to behave as rm/mv do now. > > Any o

Re: [fossil-users] Justification for two-step mv and rm

Am 06.03.2015 um 15:46 schrieb j. van den hoff: On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna wrote: I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. personally, I would _not_ like to see a mandatory `--f

Re: [fossil-users] Justification for two-step mv and rm

On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna wrote: I'm in the 1%, too. Perhaps that's because of my OS being Windows and me being a Fossil newbie. Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common

Re: [fossil-users] Justification for two-step mv and rm

I'm in the 1%, too. Perhaps that's because of my OS being Windows and me being a Fossil newbie. Maybe me and my co-workers aren't exemplars of The Average Fossil User (current and future) but typing commands in a shell is not our common approach to move or delete files. Reference point are fil

Re: [fossil-users] Justification for two-step mv and rm

2015-03-06 1:32 GMT+01:00 jungle Boogie : > On 5 March 2015 at 12:49, Roy Marples wrote: >> Add flag -f to mv and rm to do this? >> Allows the desired feature and is sort of similar to CVS >> >> fossil mv -f file1 file2 >> fossil rm -f file1 file2 > > Yes, this seems simple and easy enough to type

Re: [fossil-users] Justification for two-step mv and rm

On 5 March 2015 at 12:49, Roy Marples wrote: > Add flag -f to mv and rm to do this? > Allows the desired feature and is sort of similar to CVS > > fossil mv -f file1 file2 > fossil rm -f file1 file2 Yes, this seems simple and easy enough to type. There may be some objections as it may be be full

Re: [fossil-users] Justification for two-step mv and rm

On Tuesday 03 Mar 2015 16:22:40 Richard Hipp wrote: > On 3/3/15, Warren Young wrote: > > Is there a good reason that “fossil mv” and “fossil rm” must be followed > > by > > OS-level mv and rm commands? I miss the behavior of Subversion which made > > these into a single step. > > When I have sug

Re: [fossil-users] Justification for two-step mv and rm

I fwiw have always found Fossil's mv and rm semantics odd. The following semantics are basically what I expected when I first started using Fossil, but extended to preserve backward compatibility. They basically do what the user intended in all cases, do they not? * fossil rm FILE: * If FILE

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 04, 2015 at 05:52:36PM -0700, Warren Young wrote: > On Mar 4, 2015, at 5:28 PM, Francis Daly wrote: > > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: > > I think that the principle of least surprise for non-users of fossil is > > (much) less important. > > I think the

Re: [fossil-users] Justification for two-step mv and rm

Just to be clear: I don't yet know what I'm going to do about rm/mv. But I am watching the discussion *very* closely and I deeply appreciate the input. Thank you all. Please continue. -- D. Richard Hipp d...@sqlite.org ___ fossil-users mailing list fo

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 5:29 PM, Ron W wrote: > > On Wed, Mar 4, 2015 at 7:05 PM, Warren Young wrote: > You can get the same effect without making yourself nervous with “fossil > revert”. > > This not mentioned in "fossil help revert". It only says "Revert to the > current repository version of FI

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 5:28 PM, Francis Daly wrote: > > On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: >> >> >> The principle of least surprise says that Fossil should behave like other >> VCSes. > > I think that the principle of least surprise for users of fossil is > that the nex

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 4, 2015 at 7:05 PM, Warren Young wrote: > > You can get the same effect without making yourself nervous with “fossil > revert”. This not mentioned in "fossil help revert". It only says "Revert to the current repository version of FILE" or to specified version. ___

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 04, 2015 at 03:49:37PM -0700, Warren Young wrote: > On Mar 4, 2015, at 3:27 PM, bch wrote: Hi there, > > Sure, but: fossil is distinct from the filesystems. DOS, ext, ffs, > > etc., etc., etc are not versioning/managment filesystems, and there > > ought to be a principle-of-least-sur

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 4:50 PM, Ross Berteig wrote: > > It has always bothered me that the command that reverses 'add' is ‘rm' You can get the same effect without making yourself nervous with “fossil revert”. This matches the behavior of Mercurial, Subversion, and Bazaar. hg forget does things yo

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 4, 2015 at 5:18 PM, Warren Young wrote: > Many filesystems and OSes combine file versioning and file management: > > https://en.wikipedia.org/wiki/Versioning_file_system > > In a sense, VCSes are a way to get such features on top of filesystems > that lack these abilities. Fossil

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 4:08 PM, David Mason wrote: > > The only problem I > see with rm is that, at first blush (looking at the table): You’re correct. If you try to remove an added but uncommitted new file, hg warns you: not removing foo: file has been marked for add (use forget to undo) hg f

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 4, 2015 at 5:09 PM, Warren Young wrote: > On Mar 4, 2015, at 10:24 AM, paul wrote: > > > > If fossil mv also moves files on a filesystem, I'd be happy with that, > so long > > as I can still use a file browser as I'm doing now. > > All other VCSes I’ve used that do one-step mv [*] co

Re: [fossil-users] Justification for two-step mv and rm

On 3/4/2015 3:08 PM, David Mason wrote: So I would endorse the change to "fossil rm" if we added a "fossil forget" command. Despite their similarities in many respects, 'mv' and 'rm' are different in this one respect. It has always bothered me that the command that reverses 'add' is 'rm', due

Re: [fossil-users] Justification for two-step mv and rm

Every time I use fossil mv/rm, I've always had to issue the corresponding mv/rm command (or equivalent commands in Windows). Can someone describe a case where one would want to call fossil mv/rm, without intending the referenced file to be moved/removed as well? To me, making fossil mv/rm perform t

Re: [fossil-users] Justification for two-step mv and rm

I agree that making fossil semantics work the same as Hg would be good. The change to mv looks perfectly reasonable. The only problem I see with rm is that, at first blush (looking at the table): hg rm -f foo is the way to remove a newly added file. It's good, as in safe, but it wouldn't occur

Re: [fossil-users] Justification for two-step mv and rm

> Personally, I thought we were talking about practical UX stuff here, not > philosophy. That's not really fair -- this discussion is *couched* in applicable philosophies. On 3/4/15, Warren Young wrote: > On Mar 4, 2015, at 3:27 PM, bch wrote: >> >>> Before you reject the idea of one-step rm t

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 3:27 PM, bch wrote: > >> Before you reject the idea of one-step rm totally > > Oh, to be clear, I'm presenting this as a thought exercise. If that’s all this is, we can send it to the philosophy department and move on to other topics. Personally, I thought we were talking a

Re: [fossil-users] Justification for two-step mv and rm

> Before you reject the idea of one-step rm totally Oh, to be clear, I'm presenting this as a thought exercise. > Many filesystems and OSes combine file versioning and file management Sure, but: fossil is distinct from the filesystems. DOS, ext, ffs, etc., etc., etc are not versioning/managment

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 1:59 PM, bch wrote: > > What you're describing here is the crux of the problem, and I think > can be fairly described as separation of concerns -- the domain of > the version control is it's controlled files, and if a file is not > handled by version control, (ie: fossil rm so

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 1:52 PM, Martin Gagnon wrote: > > On Wed, Mar 04, 2015 at 06:33:07PM +0100, Ramon Ribó wrote: >> >> - When doing "fossil rm A" >> >> * If A exists in file system, delete file A > This is another story. Sometimes, I just want to remove file from > revision control This is an

Re: [fossil-users] Justification for two-step mv and rm

On Mar 4, 2015, at 10:24 AM, paul wrote: > > If fossil mv also moves files on a filesystem, I'd be happy with that, so long > as I can still use a file browser as I'm doing now. All other VCSes I’ve used that do one-step mv [*] cope with this case transparently. They see that the on-disk file

Re: [fossil-users] Justification for two-step mv and rm

On Mar 3, 2015, at 2:22 PM, Richard Hipp wrote: > > On 3/3/15, Warren Young wrote: >> Is there a good reason that “fossil mv” and “fossil rm” must be followed by >> OS-level mv and rm commands? I miss the behavior of Subversion which made >> these into a single step. > > When I have suggested

Re: [fossil-users] Justification for two-step mv and rm

What you're describing here is the crux of the problem, and I think can be fairly described as separation of concerns -- the domain of the version control is it's controlled files, and if a file is not handled by version control, (ie: fossil rm somefile), should fossil be reaching outside of its a

Re: [fossil-users] Justification for two-step mv and rm

On Wed, Mar 04, 2015 at 06:33:07PM +0100, Ramon Ribó wrote: > I think that both worlds can live together without any problem. > > - When doing "fossil mv A B" > > * If A exists and B does not exist in file system, rename file A to B > * If B exists and A does not exist in file system, do nothing

Re: [fossil-users] Justification for two-step mv and rm

I think that both worlds can live together without any problem. - When doing "fossil mv A B" * If A exists and B does not exist in file system, rename file A to B * If B exists and A does not exist in file system, do nothing * If either both exist or none exists, warn and stop - When doing "foss

Re: [fossil-users] Justification for two-step mv and rm

On 03/03/15 22:27, j. van den hoff wrote: On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp wrote: On 3/3/15, Warren Young wrote: Is there a good reason that “fossil mv” and “fossil rm” must be followed by OS-level mv and rm commands? I miss the behavior of Subversion which made these into

Re: [fossil-users] Justification for two-step mv and rm

On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp wrote: On 3/3/15, Warren Young wrote: Is there a good reason that “fossil mv” and “fossil rm” must be followed by OS-level mv and rm commands? I miss the behavior of Subversion which made these into a single step. When I have suggested c

Re: [fossil-users] Justification for two-step mv and rm

I completely agree to change current mv/rm commands so as they perform the OS level operation too. It looks like an inconsistency that they do not move/remove the file in the local repository and they move/remove it in the cloned repositories. If some script breaks, it can be repaired. No problem.

Re: [fossil-users] Justification for two-step mv and rm

Something like a cmv, crm (these are off the top of my head, don't dwell on the poor names) command that is "complete mv", and "complete rm" would fit the bill, where it appropriately wraps the current mv/rm commands is feasible, though. -bch On 3/3/15, Richard Hipp wrote: > On 3/3/15, to...@ac

Re: [fossil-users] Justification for two-step mv and rm

On 3/3/15, to...@acm.org wrote: > You could always have a global setting on how to deal with this (old way vs > new way) to keep everyone happy :) > So nobody would ever know what the "mv" and "rm" commands actually do without first consulting their settings. No. I think that is a very bad solu

Re: [fossil-users] Justification for two-step mv and rm

You could always have a global setting on how to deal with this (old way vs new way) to keep everyone happy :) -Original Message- From: Richard Hipp Sent: Tuesday, March 03, 2015 11:22 PM To: Fossil SCM user's discussion Subject: Re: [fossil-users] Justification for two-step mv a

Re: [fossil-users] Justification for two-step mv and rm

On 3/3/15, Warren Young wrote: > Is there a good reason that “fossil mv” and “fossil rm” must be followed by > OS-level mv and rm commands? I miss the behavior of Subversion which made > these into a single step. When I have suggested changing this, I got push back that the change will break exi

[fossil-users] Justification for two-step mv and rm

Is there a good reason that “fossil mv” and “fossil rm” must be followed by OS-level mv and rm commands? I miss the behavior of Subversion which made these into a single step. I’ve written scripts to wrap these, but I won’t provide them here because they don’t handle all of the cases properly.