On Thu, Dec 13, 2012 at 4:48 PM, j. v. d. hoff <veedeeh...@googlemail.com>wrote:
> On Fri, 14 Dec 2012 00:23:12 +0100, Richard Hipp <d...@sqlite.org> wrote: > > On Thu, Dec 13, 2012 at 6:08 PM, Eric <e...@deptj.eu> wrote: >> >> On Thu, 13 Dec 2012 12:55:55 -0500, "Altu Faltu" <altufa...@mail.com> >>> wrote: >>> > In order to continue the debate: >>> > In my work flow, I do rm or mv in file system as and when needed. I do >>> > fossil rm or fossil mv only when reviewing my changes before commit. >>> >>> Well, yes, that is the way I do it too. I suspect that there are some >>> who do not review their changes before commit, and that many of those >>> commit way too often, essentially treating their VCS as a backup method. >>> This of course leads to junk, non-functional checkins, followed by an >>> unhealthy interest in rebase-like functionality. >>> >>> >> Well put. >> > > I don't think so, actually. I've seen misuses (sort of) and misconceptions > of SCMs here (on this list) and elsewhere. that happens. considering > serious and sane use of SCM, I'm still > perfectly sure that for the sole reason (repeated already way to often) > that the by far most frequent use case of `fossil rm' and `fossil mv' will > be a situation where > the file system should reflect the change, the default behaviour should > change. your previous suggestion in this direction did make perfect sense > to me. the present one not so much. > > so I strongly opt for a default that does the "real" thing (yes!) of > keeping repo and file system in sync (that's in my view what the SCM should > always strive for. and to relegate different behaviour to the options, not > the other way round. > > but, indeed, it is an interesting question why for heavens sake this > issue does cause such a storm on this list? I don't get it. maybe it's too > obvious to me that a default which forces me (and an estimate 99% of the > other users) to type more than necessary -- which I don't like -- (and at > the same time of running the risk of forgetting the additional actions and > starting to mess things up) is no good while others have adjusted their > mind to the current behaviour and don't want to change anything since it > currently "just works" (tm). > This is the classical divide between pragmatists (I want to get my job with with minimal pain so I can go home a play ball with my son) versus the idealists (source code management means doing x, y and z and no more and no less and I'm sorry that it will take you twice as long to do your job right *grin*). Fossil is caught between the messy world of the pragmatists and the nice tidy world of the idealists. There is no one right way to do it. One group or the other will be disappointed. When I saw that fossil was leaning more towards the idealistic side I created my fsl wrapper to make fossil workable in a real-world arena. Without my wrapper fossil would be unusable in our team. Maybe it is time for a more robust, written in C or similar, wrapper that adapts fossil for the pragmatists allowing the idealists to have their pristine usage model. Is this something that could be formally architected to be part of the fossil project? Basically it would be one tool with two faces. It is just a thought. My wrapper needs some work (I never did finish off the -r and -f for rm) but it works well enough for now. You can get it at https://chiselapp.com/user/kiatoa/repository/fsl/index and I very much welcome suggestions for improvement. Keep in mind that it is intended to make life easy for those on large teams working with large numbers of fossils (we have over two hundred fossils in use right now) in a pure Unix environment. > I can tell you from own experience that it definitely does not help to > convince svn users, e.g., that fossil is a interesting system (which it > is). and yes: this alone > sure is no argument. but it _is_ an argument if essentially all of the > "competitors" (that I know of) go for the "`scm rm/mv' act on the > filesystem as well" strategy for a reason. > > anywayt, I think everything has been said now more than once. I'll try to > keep radio silence regarding this topic from know own (see whether I'm > successful...). > > looking forward to the upcoming releases. I'll manage to use fossil in any > case. > > j. > > > >> So Altu and Eric (and also Joe Mistachkin on a back-channel) have pretty >> much convinced me at this point to keep the current behavior of "fossil >> rm" >> and "fossil mv". >> >> But, should there be an opt-in option to also make the disk changes? >> Perhaps "fossil rm abc.txt" just removes abc.txt from configuration >> management, but "fossil rm -f abc.txt" also removes it from disk? >> >> And/or should there be a warning printed: "File abc.txt removed from >> management but unchanged on disk" just to give a heads-up to newcomers who >> expect different behavior? >> >> >> > > -- > Using Opera's revolutionary email client: http://www.opera.com/mail/ > ______________________________**_________________ > fossil-users mailing list > fossil-users@lists.fossil-scm.**org <fossil-users@lists.fossil-scm.org> > http://lists.fossil-scm.org:**8080/cgi-bin/mailman/listinfo/**fossil-users<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
