Re: [fossil-users] Justification for two-step mv and rm
2015-03-09 23:06 GMT+01:00 Tontyna tont...@ultrareal.de: 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 ___ 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] Justification for two-step mv and rm
Am 09.03.2015 um 10:09 schrieb Jan Nijtmans: Done now: http://www.fossil-scm.org/index.html/info/8cf976d24689ae9e 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 `addremove` become `addforget`? (Sorry, couldn't resist nitpicking.) ___ 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] Justification for two-step mv and rm
2015-03-06 16:58 GMT+01:00 Jan Danielsson jan.m.daniels...@gmail.com: 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 cheering you on. Done now: http://www.fossil-scm.org/index.html/info/8cf976d24689ae9e This means that whatever happens with fossil rm|mv|delete, the fossil rename and fossil forget will continue to function as they do now. Regards, Jan Nijtmans ___ 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] 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 tont...@ultrareal.de 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 would _not_ like to see a mandatory `--forcefilesystem' option in order to get the usually desired behaviour. This discussion does seem to be taking more-or-less the same shape as the last time around. The end result then was: no change; whatever code was written was not accepted into stock fossil. This time, there is some code visible in the recent timeline, so maybe it will progress. I think there were three main issues brought up, with some opinions for and against each. I'll (try to) summarise them here; but do feel free to check and correct me if I've mischaracterised anything. * the current fossil commands mv and rm make changes to the repository, but not to the local filesystem. Issue 1 - there should be a way, in fossil, to make the corresponding changes to the filesystem. Issue 2 - that way should be the default for a command, not requiring a --option argument. Issue 3 - that command should be exactly mv or rm. Issue 1 seemed to be generally positive, with a few questions about when exactly the filesystem changes should happen -- at command time or at commit time -- and with a question about what revert or other undo features should be available. Issue 2 seemed to be generally positive (once issue 1 is considered accepted); I don't think I saw any objections to the theory of it. Issue 3 seemed to be mixed. Those in favour were greatly in favour; those against were greatly against. The arguments were broadly what was seen in this thread, which is roughly: consistency with non-fossil things vs consistency with previous-fossil things. I don't think I've anything new to bring to the discussion. Hopefully the above notes are useful to clarify thoughts or recollections. Or possibly they are wrong or unsubtle enough to induce someone to expand on them. When the code is ready, it'll be time for the One Person to use the One Vote, and we'll see what's in the next version of fossil ;-) f -- Francis Dalyfran...@daoine.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] Justification for two-step mv and rm
On Fri, 06 Mar 2015 15:11:31 +0100, Tontyna tont...@ultrareal.de 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 approach to move or delete files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. 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 `--forcefilesystem' option in order to get the usually desired behaviour. otherwise, see the previous mail by jan nijtmans which proposes a very sensible solution in my view: create a new alias `forget' for the current `rm' (which then should become the sole command performing that sort of operation (removing file from `fossil' tracking w/o touching file system) in due time -- thr sooner the better ...) and start to use the already existing `rename' instead of `mv'. this would ease the way of making rm/mv act like they really should (in the view of most people I really would say -- and that's an important criterion w.r.t. what a good default behavior should be) namely like what is happening in `hg' (I agree with warren young that the `hg' people seemingly have thought long enough about this and found a good solution and implemented enough options to cover all relevant use cases). another point which has already been made in this thread, but might be emphasized: of course `mv' and `rm' already touch the file system quite regularly namely on the other end: someone updating from your repository (or your remote repo to which you (auto)sync)) after you performed `mv' or `rm' will of course modify his checkout (as indeed, it should). it makes (usually, but not always I admit) no sense that locally one has to go again and again through the routine of mirroring each and every `fossil rm' and `fossil mv' by a corresponding file system action. I understand that some people _want_ this but there needs would be satisfied if that is achieved by `rename/forget' in the future. -Tontyna BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. Am 04.03.2015 um 18:24 schrieb paul: On 03/03/15 22:27, j. van den hoff wrote: . so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. 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. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ 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] 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 tont...@ultrareal.de 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 `--forcefilesystem' option in order to get the usually desired behaviour. I totally agree, the --forcefilesystem was just a reminisence to the '-f' option proposed in previous mails. Too many options for any command are puzzling, always have to lookup what the command does depending on the applied flags. otherwise, see the previous mail by jan nijtmans which proposes a very sensible solution in my view: create a new alias `forget' for the current `rm' (which then should become the sole command performing that sort of operation (removing file from `fossil' tracking w/o touching file system) in due time -- thr sooner the better ...) and start to use the already existing `rename' instead of `mv'. this would ease the way of making rm/mv act like they really should (in the view of most people I really would say -- and that's an important criterion w.r.t. what a good default behavior should be) namely like what is happening in `hg' (I agree with warren young that the `hg' people seemingly have thought long enough about this and found a good solution and implemented enough options to cover all relevant use cases). On Windows neither `mv` nor `rm` does suggest anything to me other than what `fossil help` tells; but since the majority here associates touch the file system with those words it seems to be a good idea to let the commands exactly do that. I don't mind how the commands are named as long as they exist. Much cleaner to have different commands for different tasks. Even better when the command is self-explanatory. another point which has already been made in this thread, but might be emphasized: of course `mv' and `rm' already touch the file system quite regularly namely on the other end: someone updating from your repository (or your remote repo to which you (auto)sync)) after you performed `mv' or `rm' will of course modify his checkout (as indeed, it should). it makes (usually, but not always I admit) no sense that locally one has to go again and again through the routine of mirroring each and every `fossil rm' and `fossil mv' by a corresponding file system action. I understand that some people _want_ this but there needs would be satisfied if that is achieved by `rename/forget' in the future. Good to mention that point -- almost forgot that one of the reasons to introduce a CVS instad of only syncing directories is the question of how to get rid of unused garbage (there is always at least one developer creating 'old/', '.keep' an the likes an never deleting anything just in case) ___ 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] 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 files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. I'd prefer that default `rm`/`mv` without options leave my file system alone. A `--forcefilesytem` flag would be a convenient enhancement. -Tontyna BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. Am 04.03.2015 um 18:24 schrieb paul: On 03/03/15 22:27, j. van den hoff wrote: . so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. 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. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ 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] Justification for two-step mv and rm
2015-03-06 1:32 GMT+01:00 jungle Boogie jungleboog...@gmail.com: On 5 March 2015 at 12:49, Roy Marples r...@marples.name 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 featured, though. The biggest problem with fossil rm and fossil mv is that it suggests to remove/move a file on the file system, but it doesn't. In stead it makes fossil forget/rename the file in the repository. 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 objections against adding fossil forget as alias to fossil rm If not, I'll be glad to add it, awaiting further discussion. Regards, Jan Nijtmans ___ 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] 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 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 cheering you on. /Jan ___ 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] Justification for two-step mv and rm
On Fri, Mar 6, 2015 at 9:11 AM, Tontyna 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 files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. I am curious which IDE you and your team are using. Also, why you chose to write a stand-alone GUI application for Fossil rather than configure your IDE to interact with Fossil. Curiously, I've found that the open source IDEs I've tried actually make it harder to integrate new VCSs. Up until recently, my team and I used the SlickEdit IDE. It has very easy to configure support for any command line VCS. (Sadly, when the company decided to not renew the support contract, a manager in IT decided that meant we no longer had a license to use it - despite the fact that the license itself stated it is a perpetual license for the specified version.) ___ 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] 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 tont...@ultrareal.de 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 files. Reference point are files on a harddrive actually belonging to a specific software project which are managed and altered via IDE and file browser and afterwards confirmed (not performed) in fossil. Fossil should not interfere with that worklflow. BTW: As soon as I started exploring Fossil I startet developing a GUI application to comfortably operate Fossil. My GUI is much alike Paul's `fcommit`. I am curious which IDE you and your team are using. Also, why you chose to write a stand-alone GUI application for Fossil rather than configure your IDE to interact with Fossil. It's mainly Embarcadero Delphi and of course it's possible to write widgets or post-build-scripts to do basic stuff and for shure I'll do that. Root cause for the GUI is: To incline my boss towards Fossil we need something he will integrate without grumbling into his personal workflow. Some other reasons are - explore Fossil in a comfortable way - our products contain many files the IDE has no clue of - psycho-wise it serves the feeling of being in charge ___ 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] Justification for two-step mv and rm
On Tuesday 03 Mar 2015 16:22:40 Richard Hipp wrote: On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. 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 Roy ___ 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] Justification for two-step mv and rm
On 5 March 2015 at 12:49, Roy Marples r...@marples.name 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 featured, though. -- --- inum: 883510009027723 sip: jungleboo...@sip2sip.info xmpp: jungle-boo...@jit.si ___ 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] 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 fossil rm A * If A exists in file system, delete file A * if A does not exist in file system, do nothing RR 2015-03-04 18:24 GMT+01:00 paul pault.eg...@gmail.com: On 03/03/15 22:27, j. van den hoff wrote: On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp d...@sqlite.org wrote: On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. IIRC there was a lot of aversion at that time on the list along the line fossil should not mess with my file system which I personally found (and still find) essentially non-sequitur (since every `fossil up' does of course cause changes of the checkout content anyway). I'm also not sure what scripts would break and what the amount of work would be to fix those scripts (except removing the OS-level `mv' and `rm' actions if those were then executed by fossil itself) in comparison to getting an overall preferable behaviour (in my view, anyway). so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. 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. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ 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] 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 d...@sqlite.org wrote: On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. IIRC there was a lot of aversion at that time on the list along the line fossil should not mess with my file system which I personally found (and still find) essentially non-sequitur (since every `fossil up' does of course cause changes of the checkout content anyway). I'm also not sure what scripts would break and what the amount of work would be to fix those scripts (except removing the OS-level `mv' and `rm' actions if those were then executed by fossil itself) in comparison to getting an overall preferable behaviour (in my view, anyway). so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). I'm in the 1%. I prefer _not_ to use the command line. So if I want to move a file or directory I usually do that with a file browser. Same for deleting. When I eventually come to doing a check-in, renamed/deleted files show up in the missing tab of my fcommit GUI (*), and it's then, using the GUI, that I tell fossil what I've done, and then I commit. 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. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. Regards, Paul (*) www.p-code.org/fcommit ___ 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] 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 * If either both exist or none exists, warn and stop This make sense to me.. - 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, but I still want to keep the file on my filesystem. So for fossil rm, I would prefer to don't touch the file system by default. * if A does not exist in file system, do nothing snip Regards, -- Martin G. ___ 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] 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 area of responsibility, well-intentioned or not ? -bch On 3/4/15, Martin Gagnon eme...@gmail.com wrote: 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 * If either both exist or none exists, warn and stop This make sense to me.. - 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, but I still want to keep the file on my filesystem. So for fossil rm, I would prefer to don't touch the file system by default. * if A does not exist in file system, do nothing snip Regards, -- Martin G. ___ 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] Justification for two-step mv and rm
On Mar 3, 2015, at 2:22 PM, Richard Hipp d...@sqlite.org wrote: On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. Surely we can abandon such considerations at the 2.0 mark, if not before. Of the commonly-used open source VCSes (cvs, svn, bzr, hg, git) Fossil is currently the odd VCS out in requiring two-step rm *and* mv. Subversion, Mercurial, Git and Bazaar all do one-step mv. CVS doesn’t do one-step mv, but that’s because it doesn’t do mv at all. As for rm, there’s quite a lot of variance: CVS leaves the working copy alone unless you give -f. Subversion does the opposite: one-step rm unless you give --keep-local. I think this is another case of Subversion fixing a CVS problem: the wish for local removal is likely the more common case. Git is like Subversion except that there is nothing like --keep-local. I assume this is because it will only work on versioned files, so you have a copy in the Git history. The only problem I have with this logic is that it means you can trash uncommitted edits without warning. Bazaar is like Fossil: no local removal, and no CVS-like -f option to force it. I’m pretty sure Fossil isn’t trying to emulate bzr, though. Mercurial has a complex decision table for what rm does depending on the state of the file and the flags you give: http://www.selenic.com/mercurial/hg.1.html#remove This table clearly distills some serious thinking about the Right Thing which might be worth emulating in Fossil. In particular, it solves my complaint about how Git treats uncommitted changes. It also solves Paul’s problem. Anyone worried about changing the current Fossil behavior should puzzle their way through this table and see if they can see a common use case that isn’t covered. I know I’d be happy if Fossil worked like this, though I personally have never had a problem in a dozen years of using Subversion and its less-careful design. I’ll survey other VCSes if anyone cares. I just stopped here because that’s pretty much all the commonly-used open source ones today. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 10:24 AM, paul pault.eg...@gmail.com 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 is already moved, so they just take your command as a request to reflect the change in the repo, too. If I want to move a file on my hard drive, I think I should be able to do it however I like, whether it's managed by a version control system or not. I recommend that you work through the Mercurial decision table for hg remove: http://www.selenic.com/mercurial/hg.1.html#remove I think it addresses your concerns. To summarize, it will only do an unconditional removal if given -f or if you are asking it to remove a file that’s already in the repo, with no local changes. [*] Which is to say, every VCS I’ve never used except for CVS which doesn’t do mv at all. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 1:52 PM, Martin Gagnon eme...@gmail.com 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 exceptional case, which means it should be dealt with by a flag. Subversion does it with --keep-local, and Mercurial does it with -Af. ___ 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] 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, extn, ffs, etc., etc., etc are not versioning/managment filesystems, and there ought to be a principle-of-least-surprise/being-a-good-citizen kept in mind. In a sense, VCSes are a way to get such features on top of filesystems that lack these abilities. Well... sure -- but is that what I (or everybody, the majority, some appropriate entity) signed up for when I started using fossil ? Is it a Good Thing, or again, as case of overstepping bounds ? Honest question. I'll review your linked paper on hg for more ideas. Cheers, -bch On 3/4/15, Warren Young w...@etr-usa.com wrote: On Mar 4, 2015, at 1:59 PM, bch brad.har...@gmail.com 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 somefile), should fossil be reaching outside of its area of responsibility, well-intentioned or not ? 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. Before you reject the idea of one-step rm totally, work your way through the table documenting Mercurial's approach: http://www.selenic.com/mercurial/hg.1.html#remove Do you see a problem if Fossil worked that way, too? ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 3:27 PM, bch brad.har...@gmail.com 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 about practical UX stuff here, not philosophy. Many filesystems and OSes combine file versioning and file management Sure, but: fossil is distinct from the filesystems. DOS, extn, ffs, etc., etc., etc are not versioning/managment filesystems, and there ought to be a principle-of-least-surprise/being-a-good-citizen kept in mind. The principle of least surprise says that Fossil should behave like other VCSes. Fossil is odd-man-out for mv, and emulates #5 in popularity on the list of VCSes I surveyed for rm. The principle says it should be emulating #1-3 instead. I’m ranking VCS popularity as git, svn, hg, cvs, bzr, fossil based on this table: http://goo.gl/M7ogNH That matches pretty well with what I see used in the wild. Is it a Good Thing, or again, as case of overstepping bounds ? Honest question. One of Fossil’s primary virtues is uncommon simplicity for a DVCS. It isn’t as simple as svn, but wherever possible, it generally takes no more work to do something in Fossil as in svn. I’m proposing that we fix one of the remaining usability gaps. I'll review your linked paper on hg for more ideas. It’s just several brief paragraphs of text and a 5x5 table. It’ll only take you a few minutes to get through. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 4:50 PM, Ross Berteig r...@cheshireeng.com 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 you probably don’t want, or at least aren’t thinking about right now. It means “make the repo forget this file on this branch henceforth.” It’s like “svn rm --keep-local”, not at all like “svn revert”. It just happens to give the same effect in this particular case. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 5:28 PM, Francis Daly fran...@daoine.org 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 next version of fossil should be pretty much the same as the current version, only better. I think that the principle of least surprise for non-users of fossil is (much) less important. I think there are many times more future users of Fossil than present users of Fossil. It will be easier to woo them if we’re not throwing pointless differences in their way. We’re at a really good point to be making behavioral changes to Fossil right now. We have the upcoming 2.0 break point, the FLOSS Weekly interview should start moving the adoption needle, and the continuing popularity of SQLite will keep slipping Fossil into all kinds of strange places. The time to be conservative is when you have a huge installed base. For both better and worse, Fossil doesn’t have that yet. For what it's worth, I do think that it would be useful to have a command to affect both the repository and the filesystem in similar ways. But I also think that historical baggage suggests that rm (or mv) is not that command. There really isn’t any historical baggage with mv. Fossil’s the weird one here. As for rm, you could be right. The only semantic agreement I found in my survey is probably accidental rather than intended. Still, I don’t see what’s wrong with making fossil rm behave the same as POSIX rm. There are an awful lot of people who have hard-won muscle memory that keeps them from shooting themselves in the foot with rm(1). It should protect them with fossil rm, too. (I confess that I'm not clear on exactly how (or whether) undo or revert will become involved in the new remove-from-repository-and-filesystem command/argument. fossil mv is easy. It’s inherently undoable. The Mercurial approach to rm addresses this concern, too. It won’t allow rm without -f if you have uncommitted local modifications. If you force it, you’ve already given up on undo, IMHO. The tool tried to protect you from a potential data loss, and you made it proceed anyway. I suppose if one wanted to be *really* conservative, one could make Fossil delay the local filesystem delete until commit. It would be inconsistent with other VCSes' implementations of rm, with POSIX rm, and with the new Fossil mv. I don’t know that this margin of safety is worth the inconsistency. ___ 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] 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 w...@etr-usa.com wrote: On Mar 4, 2015, at 3:27 PM, bch brad.har...@gmail.com 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 about practical UX stuff here, not philosophy. Many filesystems and OSes combine file versioning and file management Sure, but: fossil is distinct from the filesystems. DOS, extn, ffs, etc., etc., etc are not versioning/managment filesystems, and there ought to be a principle-of-least-surprise/being-a-good-citizen kept in mind. The principle of least surprise says that Fossil should behave like other VCSes. Fossil is odd-man-out for mv, and emulates #5 in popularity on the list of VCSes I surveyed for rm. The principle says it should be emulating #1-3 instead. I'm ranking VCS popularity as git, svn, hg, cvs, bzr, fossil based on this table: http://goo.gl/M7ogNH That matches pretty well with what I see used in the wild. Is it a Good Thing, or again, as case of overstepping bounds ? Honest question. One of Fossil's primary virtues is uncommon simplicity for a DVCS. It isn't as simple as svn, but wherever possible, it generally takes no more work to do something in Fossil as in svn. I'm proposing that we fix one of the remaining usability gaps. I'll review your linked paper on hg for more ideas. It's just several brief paragraphs of text and a 5x5 table. It'll only take you a few minutes to get through. ___ 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] 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 fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
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 brad.har...@gmail.com wrote: Hi there, Sure, but: fossil is distinct from the filesystems. DOS, extn, ffs, etc., etc., etc are not versioning/managment filesystems, and there ought to be a principle-of-least-surprise/being-a-good-citizen kept in mind. 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 next version of fossil should be pretty much the same as the current version, only better. I think that the principle of least surprise for non-users of fossil is (much) less important. I think that the last few times this topic came up on the list, there was not a clear enough consensus that changing some fossil commands to do something (potentially) destructive which they are explicitly documented not to do, that the patches were not accepted. Perhaps this time it will be different. For what it's worth, I do think that it would be useful to have a command to affect both the repository and the filesystem in similar ways. But I also think that historical baggage suggests that rm (or mv) is not that command. The matrix in the hg remove documentation does cover many (possibly all?) cases. Perhaps a fossil remove command could act just like it? With a fossil move command to do fossil mv + suitable filesystem manipulations? (I confess that I'm not clear on exactly how (or whether) undo or revert will become involved in the new remove-from-repository-and-filesystem command/argument. I think I didn't understand it the last time around, either.) But one thing I know, is that I won't be the one writing the patches, or deciding whether they go into stock-fossil. Cheers, f -- Francis Dalyfran...@daoine.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] 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 fran...@daoine.org 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 there are many times more future users of Fossil than present users of Fossil. Potential future users, yes. But (selfishly) they are not my concern. Other opinions exist, of course. It will be easier to woo them if we’re not throwing pointless differences in their way. Wooing them is not my ambition. Disturbing current actual users, few though they may be, is a definite negative. Possibly the positive for current actual users who want the behaviour change, plus whatever positive is associated with future users who will benefit from the behaviour change, outweighs the negative. That's a balance for the project to decide. For what it's worth, I do think that it would be useful to have a command to affect both the repository and the filesystem in similar ways. But I also think that historical baggage suggests that rm (or mv) is not that command. There really isn’t any historical baggage with mv. Fossil’s the weird one here. Some historical baggage is that right now, one (reasonable?) way to commit a file rename is fossil mv a b mv a b fossil commit -m mv If you're going to break that, do it deliberately and loudly. (I confess that I'm not clear on exactly how (or whether) undo or revert will become involved in the new remove-from-repository-and-filesystem command/argument. fossil mv is easy. It’s inherently undoable. I'm sure it can be, for all combinations of files and directories which do and do not exist before the fossil repo+fs-mv, and which are created after that and before any undo. But there's a whole new (I think) set of error cases in there. (I may be wrong; they may already be covered by checkout, which would ease the documentation burden.) The Mercurial approach to rm addresses this concern, too. It won’t allow rm without -f if you have uncommitted local modifications. If you force it, you’ve already given up on undo, IMHO. The tool tried to protect you from a potential data loss, and you made it proceed anyway. Once the error indication and the recovery advice are clear, it'll be fine for interactive use or new scripting use. f -- Francis Dalyfran...@daoine.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] 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 is unmanaged, then error out (without deleting FILE). * if FILE is managed but does not exist, then apply current semantics (i.e. stage for removal at commit time). * If FILE is managed and exists, then do a filesystem remove of FILE and then apply current semantics.[1] * fossil mv A B: (1) if A is unmanaged, then error out. (2) if A and B are both managed, then apply current semantics (i.e. error out). (3) if A is managed, A does not exist, and B exists but is not managed, then then apply current semantics. (4) if A is managed and A exists: * if B does not exist, do a filesystem rename of A to B and then apply current semantics (3) * if B exists, then error out. (I am not a fan at all of the current semantics, in which B is irrevocably deleted if initially unmanaged after 'fossil mv A B; fossil revert', so am trying to smuggle a fix for that in here:-) Maybe I'm missing sub-cases, but the key thing is that I expect Fossil to do the filesystem 'rm' or 'mv' for me if it's safe to do so. And I think Fossil can preserve backward compat even if extended in this way, right? Eric [1] Consider first checking for changes against current check-in and erroring out if file is 'dirty' (recommending revert first), which I think Git does. ___ 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] 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 the filesystem mv/rm as well would save me a step. Looking back, this behavior would have saved me many steps. I think it's a good thing if fossil reduces the amount of manual work that we need to perform. On Wed, Mar 4, 2015 at 3:08 PM, David Mason dma...@ryerson.ca wrote: 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 to me (because rm -f in the shell is so total). And I actually needed to do this a couple days ago. Actually, it turns out that the right way to do it is: hg forget foo So I would endorse the change to fossil rm if we added a fossil forget command. ../Dave ___ 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] Justification for two-step mv and rm
On Wed, Mar 4, 2015 at 5:09 PM, Warren Young w...@etr-usa.com wrote: On Mar 4, 2015, at 10:24 AM, paul pault.eg...@gmail.com 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 is already moved, so they just take your command as a request to reflect the change in the repo, too. I suppose the VCS could match the hashes of the missing files to the hashes of the new files to detect any moved/renamed files. However, that fails if the moved files were also edited, so there would still have to a way to explicitly tell the VCS about moved/renamed files. ___ 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] Justification for two-step mv and rm
On Wed, Mar 4, 2015 at 5:18 PM, Warren Young w...@etr-usa.com 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 can act as a FUSE server. I haven't tried it, so I don't know if it's possible to check-in files by writing them in to the mounted file system. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 4:08 PM, David Mason dma...@ryerson.ca 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 forget isn’t just “forget uncommitted changes,” though, it’s more like “svn rm --keep-local”. That is, it removes the file from the repo, but leaves the local copy behind. hg rm -f foo is the way to remove a newly added file. It's good, as in safe, but it wouldn't occur to me (because rm -f in the shell is so total). Yeah, that’s a bit of a strange design decision. I could argue either side of it, but I don’t really see a point in making Fossil pointlessly different from all other VCSes again. If we’re going to make it emulate something, we shouldn’t bury any little design change land mines in its implementation. Actually, it turns out that the right way to do it is: hg forget foo Fossil, Mercurial, Bazaar and Subversion do the same thing with “revert”. Git, in its ever-strange way, does it with “git reset file” or “git rm --cached file”. I seem to recall that CVS made you move the just-added file out of the way, revert the tree, then move it back. Bleah. The reason hg has two ways to achieve the same end is that the two commands are semantically different, but just *happen* to achieve the same end. hg forget says, “Take this file out of the repo, but leave the local copy.” hg revert says, “Disregard my request to add this local file to the repo.” So I would endorse the change to fossil rm if we added a fossil forget command. fossil revert already provides this. ___ 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] Justification for two-step mv and rm
On Wed, Mar 4, 2015 at 7:05 PM, Warren Young w...@etr-usa.com 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. ___ 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] Justification for two-step mv and rm
On Mar 4, 2015, at 5:29 PM, Ron W ronw.m...@gmail.com wrote: On Wed, Mar 4, 2015 at 7:05 PM, Warren Young w...@etr-usa.com 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. I tested it here before posting. You get back “UNMANAGE foo”, which tells me Fossil knows what I meant. I don’t think I ever looked in the manual for this. I just tried doing it the Subversion way, and found that it did what I expected, so that’s what I’ve always done. ___ 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] 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 to the overloaded meanings attached to 'rm'. It has never felt comfortable to back out a mistaken 'fossil add' with 'fossil rm' out of fear that the target file might get deleted when all that is meant is to drop it from version control. So I like the idea of a 'forget' command. It is a word that has no strong pre-existing file system semantics attached. That said, having 'fossil rm' also 'forget' the target seems sane. So does requiring an override if the target has uncommitted changes. I'd also argue that 'fossil rm' should ignore files that are not currently under version control, that is it should remain separate from the ordinary 'rm' utility. In any case, having 'fossil mv' take care of the file system as well makes sense, especially if it recognizes the other common case of something else having already performed the rename (shell, IDE, file browser, or something else entirely). That said, if both the old and new names exist it should probably fail without changing anything. All that said, as a bearer of scars from CVS's disregard for renames and disrespect for deletes, the fact that fossil can and does get it right has been very welcome. -- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ ___ 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] 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. RR 2015-03-03 23:12 GMT+01:00 bch brad.har...@gmail.com: 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 d...@sqlite.org wrote: On 3/3/15, to...@acm.org 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 solution. -- 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 ___ 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] Justification for two-step mv and rm
On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. -- 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] Justification for two-step mv and rm
On 3/3/15, to...@acm.org 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 solution. -- 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] 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 and rm On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. -- 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 ___ 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] 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 d...@sqlite.org wrote: On 3/3/15, to...@acm.org 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 solution. -- 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 ___ 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] Justification for two-step mv and rm
On Tue, 03 Mar 2015 22:22:40 +0100, Richard Hipp d...@sqlite.org wrote: On 3/3/15, Warren Young w...@etr-usa.com 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 existing scripts. IIRC there was a lot of aversion at that time on the list along the line fossil should not mess with my file system which I personally found (and still find) essentially non-sequitur (since every `fossil up' does of course cause changes of the checkout content anyway). I'm also not sure what scripts would break and what the amount of work would be to fix those scripts (except removing the OS-level `mv' and `rm' actions if those were then executed by fossil itself) in comparison to getting an overall preferable behaviour (in my view, anyway). so, I would second the OP's request to make fossil behave essentially like svn (or hg) regarding `mv' and `rm'. I'm quite sure that would be the better behaviour in the overwhelming number of use cases (i.e. right now I would guess that in 99 out of 100 cases `fossil mv/rm' is followed by the corresponding os-level command, so ...). -- Using Opera's revolutionary email client: http://www.opera.com/mail/ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
