Re: [fossil-users] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 1:24 AM, Jan Danielsson jan.m.daniels...@gmail.comwrote: I'm willing to bet that the number of times people will type fossil mv/rm X Y and not actually want to mv/rm X to Y just afterwards is vanishingly small. More to the point; let's reverse your -s-flag; I.e.: $ fossil mv X Y ... renames X to Y (metadata and filesystem). $ fossil -d mv X Y ... as in Don't actually move will only change the metadata, and the user can then use the mv command afterwards to manually rename/move the file in the filesystem. The last option doesn't make any sense at all. Which is sort of my point.. I think such an option would be used roughly zero times; but your proposed -s would be used almost 100% of the time (when people learn about it). And this goes back to that ten things I hate about git-list; when commands counter-intuitively require extra flags to get the canonical behavior. While the numbers may be in favor of the -s or whatever option, I doubt the other behavior would be used zero times. It happens occasionally that I want to remove a file from version control, but not the actual file. -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ 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] why does `fossil rm' not do the real thing?
As I understand it, fossil currently deletes one file from disk when doing and update if this file has been removed by another user. For me, it is incoherent that fossil does not do the same on commit. Of course, only for the case that there is a copy of the file in the previous version and that there are no changes in it. In the latter case, no information can be lost, and the file is already contained in the previous version and can be checkout from there if necessary. RR 2012/12/12 Baruch Burstein bmburst...@gmail.com While the numbers may be in favor of the -s or whatever option, I doubt the other behavior would be used zero times. It happens occasionally that I want to remove a file from version control, but not the actual file ___ 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] why does `fossil rm' not do the real thing?
Le 2012-12-12 06:28, Ramon Ribó a écrit : As I understand it, fossil currently deletes one file from disk when doing and update if this file has been removed by another user. For me, it is incoherent that fossil does not do the same on commit. Of course, only for the case that there is a copy of the file in the previous version and that there are no changes in it. In the latter case, no information can be lost, and the file is already contained in the previous version and can be checkout from there if necessary. It's in that case where a -f would be useful. I would expect: fossil rm file, to remove the file on checkout if the file is in sync with the repository, but command to fail if the file is locally modified. In the case where the user really want to delete change that never get committed, he can use: fossil rm -f file That way, there's no danger of accidental data lost. If you call fossil rm by mistake, file can be retrieve from previous version on the repository. snip ___ 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] pushing only specific branches to specific servers?
On Dec 12, 2012, at 08:28 , Gour wrote: On Tue, 11 Dec 2012 18:59:59 -0600 C. Thomas Stover c...@thomasstover.com wrote: Is there some way to push just a specific branch to a server other than the private branch feature? No, but it was discussed in the past...btw, I'd also like to have selective push/pull feature. IIRC the conclusion of these discussions always was: there's no problem with that, we just need someone who wants it badly enough to implement it. Funny how this never happened. Kind regards, Remigiusz Modrzejewski ___ 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] pushing only specific branches to specific servers?
Actually it turns out I can do what I want the existing private branch feature. I noticed that on --push, --pull, and --clone there is a --private option that says to include private branches. So to use my earlier example, branch would be private, and pushes to sever1 would use the --private option. -- C. Thomas Stover Stover Enterprises, LLC ___ 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] pushing only specific branches to specific servers?
On Wed, 12 Dec 2012 12:21:41 -0600 C. Thomas Stover c...@thomasstover.com wrote: Actually it turns out I can do what I want the existing private branch feature. I noticed that on --push, --pull, and --clone there is a --private option that says to include private branches. The problem is in private branchES, iow, there is no ability to be selective. Same with getting rid of them - all or nothing. Sincerely, Gour -- But for one who takes pleasure in the self, whose human life is one of self-realization, and who is satisfied in the self only, fully satiated — for him there is no duty. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] pushing only specific branches to specific servers?
Le 2012-12-12 13:21, C. Thomas Stover a écrit : Actually it turns out I can do what I want the existing private branch feature. I noticed that on --push, --pull, and --clone there is a --private option that says to include private branches. So to use my earlier example, branch would be private, and pushes to sever1 would use the --private option. But if I understand well this --private options, it will sync *all* private branches. -- 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] applied DVCS for collaborative work - on the fossil project itself, or otherwise
blabbing I have made some great progress on my continuing quest for fire with Fossil yesterday and today. In this episode, my juggling of over-committed time cycled back around to answering questions about branching and merging in the context of various development models using Fossil. In no way am I ashamed to say this this entire area (not just with Fossil) can be exceedingly complex, and really can make an old dog feel incapable of learning new tricks. Chin up, and persevere. For all the playing around with it is very much worth the headaches. The DVCS model(s) really are powerful time amplifying tools, of which Fossil clearly is the least nonsense, most purposeful winner. /blabbing For example, to experiment with some private changes to an actively developed codebase within a publicly cloneable Fossil project, one simply (honoring licenses, etc): 1. clones it 2. makes a branch 3. hacks 4. occasionally --pull from the official project; and merge with trunk 5. optionally publicly host this repository Now for some questions and observations... If the official project maintainers would like to bring in this branch onto their own Fossil server (either to simply host it, or to attempt a merge) they can do so with a --pull. However this currently would have the consequence of the all or nothing (wiki pages, other branches, tickets) behavior. Even so, having Fossil display and generate diffs so as to allow the changes of choice to be visualized and read clearly before being patched into a forked version (official or otherwise) is still about 1000:1 sanity improvement over emailing diff attachments. A project using Fossil may host some code with a F/OSS license of some kind, but it may or may not have as copyright holders granted the right to re-host things like wiki pages. So this detail would need to be considered before hosting a clone of someone else's project. Again some type of clone/push/pull granularity might be useful to avoid a legal, courtesy, or outright malicious incident. Consider the case of a new user who wants to try out your project. So they google your project name. The user unknowingly ends up at the site of some kid who had no intention infringing on your trademark, but was instead simply trying to give back their hack, for say - GPL compliance. (contrived, but you get the point) In the case of the Fossil project specifically, what sort of steps would make it ok to say hey folks check out fossil hack, it's up on a cloned repo at url abc. Even if one was in the position of a regular contributor, they still might want to do something like this as sort of a public private branch in between contribution worthy revisions. -- C. Thomas Stover Stover Enterprises, LLC ___ 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] why does `fossil rm' not do the real thing?
Chad Perrin decía, en el mensaje Re: [fossil-users] why does `fossil rm' not do the real thing? del Miércoles, 12 de Diciembre de 2012 18:22:53: I rather suspect that, if Fossil continues to grow in usage over time, and if it fails to implement sane defaults and options like what you just described as a general policy, there will probably be either a fork or a wrapper that arrives to solve the problem. If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. -- o-= Marcelo =-o ___ 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] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) ___ 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] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote: On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] why does `fossil rm' not do the real thing?
On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin c...@apotheon.net wrote: Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Well, one thing that I don't know whether to call UI mistake, but it is certainly an inconvenience, is that to obtain accurate status information (similar to git status, bzr status, etc.) you must do fossil status ; or fossil changes fossil extras --dotfiles J ___ 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] why does `fossil rm' not do the real thing?
On Wed, Dec 12, 2012 at 3:13 PM, Chad Perrin c...@apotheon.net wrote: On Wed, Dec 12, 2012 at 03:07:51PM -0800, Themba Fletcher wrote: On Wed, Dec 12, 2012 at 3:04 PM, Richie Adler richiead...@gmail.com wrote: If that happens, please make sure to include git in the new name. That's what all the naysayers are trying to convert Fossil into, anyway. +1 :) Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Sorry for the hasty and flippant reply -- poor judgement on my part given the passion involved in this discussion. It seems to all boil down to what's a sane default and how liberal fossil should be about removing a file from the disk. I obviously prefer the current, conservative, behavior, and it's one of fossil's selling points as far as I'm concerned. This discussion has devolved somewhat into a comparison with other systems and speculation about user growth if fossil fails to conform, which I think may be getting somewhat counterproductive. I'd like to return to what I think should be the focus, which is discussing what the right thing is for fossil to do. As a possible compromise, the combination of a '-f' flag to fossil rm with the ability to add aliases (mentioned as a possible feature by Richard recently in another thread if I'm not mistaken) could solve this completely. The default could remain as is, safe and conservative, and the only downside would be the necessity of communicating the option to new users to alias 'fossil rm' to 'fossil rm -f'. I'll of course even volunteer to write the FAQ entry if this becomes a reality (since I don't really have any place mucking about with fossil's internals). Again, my apologies for adding noise earlier to an important discussion. -- Chad Perrin [ original content licensed OWL: http://owl.apotheon.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] why does `fossil rm' not do the real thing?
If we're talking about adding git to the name because of this whole rm thing, we might as well consider mercurial as a candidate too. Mercurial behaves sensibly and removes the file automatically on rm. Naysayers aren't trying to make Fossil Git, we're just trying to make it do what most other VCSs do in these areas. On 12/12/2012 05:38 PM, Juanma Barranquero wrote: On Thu, Dec 13, 2012 at 12:13 AM, Chad Perrin c...@apotheon.net wrote: Screw that. Git makes exactly the kind of UI mistakes I'm talking about eliminating. Well, one thing that I don't know whether to call UI mistake, but it is certainly an inconvenience, is that to obtain accurate status information (similar to git status, bzr status, etc.) you must do fossil status ; or fossil changes fossil extras --dotfiles J ___ 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] why does `fossil rm' not do the real thing?
On 12/12/2012 08:42 PM, Richie Adler wrote: What's next? Replacing SQLite with individual files? Absolutely not, and statements like this do more harm than good because they willfully disregard the point of what is being expressed. The point is not to be alarmist and extreme, as statements like the above are. The point is to establish that there is a certain behavior that is expected, and Fossil does not exemplify that. Saying next you'll want to change the file format is silly, because expectations about a thing like file format are *nowhere near the same category* as something like what rm should do. In day to day operation, I care nothing about the file format. I care a whole lot more about whether or not I have to perform several operations to remove a file, when Fossil as a tool could make that work easier for me and not sacrifice data as several posters have already noted. ___ 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] why does `fossil rm' not do the real thing?
On Wed, 12 Dec 2012 23:42:29 -0300 Richie Adler richiead...@gmail.com wrote: Sorry, I still think that the intention is to destroy what Fossil has of unique to offer to be able to say that Git or Mercurial it's the same and they should be preferred to Fossil. What's next? Replacing SQLite with individual files? Can you please change your mantra labelling every constructive attempt to change something in Fossil as conspiracy by Git advocates. Thank you. Sincerely, Gour -- As a strong wind sweeps away a boat on the water, even one of the roaming senses on which the mind focuses can carry away a man's intelligence. http://www.atmarama.net | Hlapicina (Croatia) | GPG: 52B5C810 ___ 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] why does `fossil rm' not do the real thing?
Nolan Darilek no...@thewordnerd.info writes: If we're talking about adding git to the name because of this whole rm thing, we might as well consider mercurial as a candidate too. Mercurial behaves sensibly and removes the file automatically on rm. Naysayers aren't trying to make Fossil Git, we're just trying to make it do what most other VCSs do in these areas. Speaking as someone who has absolutely no investment--emotional, professional, or otherwise--in any VCS other than fossil (and also as a non-programmer), is what most other VCSs do so important? Seems like--while there's certainly potential room for tweaking--there's a fundamental disconnect, philosophically, between 1) what is in the filesystem 2) what is kept in version control and while the twain shall meet occasionally (to say the least), they are not *necessarily* the same. Fossil, after all, is a version control system, not a filesystem management system. It seems wholly natural to me that fossil rm x should mean remove the file x from version control, since version control is fossil's raison d'etre. To my way of thinking, VCSs which also really delete the file when removing it from version control are violating their fundamental paradigm. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
