[fossil-users] FYI - fossil on n900 works great. Using as sync for zim
Just in case it piques anyones interest, I'm using fossil on my n900 phone to sync zim data to from my desktop and netbook. I like the fit between zim and the "Getting Things Done" methodology ( http://zim-wiki.org/manual/Usage/Getting_Things_Done.html). I just installed scratchbox (aprox 1/2 hr) and thanks to no dependencies fossil compiled effortlessly. The fossil ui works perfectly and performance is fast enough. My checkout is 16M, the fossil db is 250M (data goes back to 1992). Now what'd be really cool would be a melding of fossil and zim features - there is a lot of overlap. Dreams are cheap :) And for a complete OT paragraph: If you are not following the dotfiles discussion please vote "don't care" in the poll at http://www.easypolls.net/poll.html?p=4eda64df4fb7b0e46a6feea2 Cheers, Matt -=- ___ 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] hidden files on linux support?
On Sat, Dec 3, 2011 at 4:16 AM, Eric wrote: > On Fri, December 2, 2011 11:39 pm, Matt Welland wrote: > > On Fri, Dec 2, 2011 at 4:03 PM, Eric wrote: > > > >> On Fri, December 2, 2011 7:26 pm, Stephan Beal wrote: > >> > On Fri, Dec 2, 2011 at 8:17 PM, Eric wrote: > >> > > >> >> Why on earth would you want to? > >> >> > >> >> I know others have offered suggestions and explanations for how to do > >> >> it, > >> >> but I would never have a "dotfile" (or a symlink for that matter) in > >> a > >> >> repository, so I'm really asking about the use-case. > >> >> > >> >> > >> > Think ".gitignore" and friends. Some tools support files like that for > >> > holding various metadata (some non-git tools support .gitignore). > >> > > >> > http://gitready.com/beginner/2009/01/19/ignoring-files.html > >> > > >> > >> Oh, I know about those. But they are one of > >> > >> 1) needed at build or install time, in which case the build and install > >> scripts create them > >> > >> 2) part of my common development environment, in which case they are not > >> part of what I am developing and do not belong in its repository > >> > > > > Do I detect a hint of judgment in your post Eric? > > Of course. It's what I do, and what I think should be done so I will, > from time to time, say so. Others are free to disagree; and to negotiate > if we are working together. > > > Items 1. and 2. are true in your world perhaps but certainly often > > not in mine. I lost an hour of my time because fossil silently ignored > > dot files that are a required critical part of a process that I moved > > from an ancient SCM into fossil. > > You won't do that again will you? :) It's part of knowing what your > tools do and what assumptions they make. For any non-trivial tool, > you will sometimes learn the hard way. > Well designed tools generally re-use the knowledge that people have garnered along the way but also keep up with the times. It would be have been a red flag for me if by default fossil only handled 8.3 DOS files without a special switch --allow-long-filenames. Design choices reflect on the values, knowledge and perceptiveness of the developers and defaulting to 8.3 would be a sign of "not Unix friendly" for me. Is fossil ignoring dotfiles on recursive add a red flag for others? I doubt it but it did take me by surprise. I put together a poll as I'm quite curious, how do others perceive this design choice? http://www.easypolls.net/poll.html?p=4eda64df4fb7b0e46a6feea2 Choosing to ignore dotfiles is a mildly surprising choice to me. But I think silently ignoring them is a rather poor choice. However, for me it was little more than an annoyance. I noticed this some time ago and just put "WARNING: fossil by default silently ignores dotfiles when adding recursively, use the --dotfiles to add them." in my training documentation and moved on. > Personally I prefer my tools to let me know if i say "add" and they > choose not to do so however the --dotfiles switch suffices. How verbose should a tool be? There will probably always be cases the tool > author(s) never even thought of. And is it really the tool anyway? For > "fossil add *" on *ix, fossil doesn't know that it is skipping dotfiles, > because the shell has already done that. > The use case under discussion is in adding a directory with all it's contents - not in adding files with "*". I don't think anyone in this thread is expecting * to expand to dotfiles. Here is how some of the tools I happen to be familiar with behave: git - adds the dotfiles subversion - adds the dotfiles monotone - ignores .svn and .git but tells you about it. adds other dot files. cvs - I'm pretty sure .* is not part of the default ignore list, i.e. adds dot files And of course all copying tools such as rsync and tar capture the dotfiles. Can someone point out some tools for revision control or copying data that silently ignore dotfiles? > There are a few interesting arenas where "source" is not C, nor any > other language you are likely to deal with as a "normal" programmer and > yet these arenas can make good use of a tool like fossil and some even > pay pretty dang good and maybe even deserve a bit of respect :) Not arguing with that at all. > > Eric > > -- > ms fnd in a lbry > > > ___ > 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] hidden files on linux support?
Am Samstag, den 03.12.2011, 12:28 + schrieb Eric: > On Sat, December 3, 2011 10:56 am, Barry Kauler wrote: > >>> fossil add --dotfiles . > >>> > >> that's exactly what I searched for. Is there a way to make this > >> behaviour default for a repository? > > > > I would very much like this too please. > > I am a newcomer to Fossil, was quite surprised that hidden files are > > left out by default. > > Why? What is the definition of "hidden". > Hidden is, what you cannot see directly. > > Note, my Fossil repo has hidden files, symlinks, binary files, empty > > directories, and files/directories with special permissions/ownership! > > Your project has these things. To the extent that my projects have them, > I deal with them with setup, build, and install scripts. I don't actually > see why people expect a newly-made checkout (working) directory to behave > in all respects like an installed copy of the project. This is not what > the SCM tools are designed for. > SCM tools are designed to manage all changes made to the project. If a team works on a software, agreed on the usage of an IDE and manage the project entirely with an IDE, the settings made to the project in the IDE have to be part of the repository as well as the source itself. If one programmer addes external binary libraries, all other programmers should get this libraries, as well as the settings in the project of the IDE to include them through the VCS. Since VCS, especially DVCS aim to be used by multiple programmers working on one project, the default settings should be focused on that, instead of single programmers. But that leads far off-topic, so please don't spam the topic further with 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] hidden files on linux support?
>> I am a newcomer to Fossil, was quite surprised that hidden files are >> left out by default. > > Why? What is the definition of "hidden". I probably should not be buying into this discussion, as I'm a newcomer. But anyway, I place files with a dot in front of them into a project because they are intended to be in the project. That's what anyone would do. So why should Fossil screen them out? A hidden file is just a file that is not normally visible. This usually pertains to the end user, when someone installs the project. I can't see any reason whatsoever why Fossil should screen them out. It does not matter whether this is Unix/Linux or not. >> Note, my Fossil repo has hidden files, symlinks, binary files, empty >> directories, and files/directories with special permissions/ownership! > > Your project has these things. To the extent that my projects have them, > I deal with them with setup, build, and install scripts. I don't actually > see why people expect a newly-made checkout (working) directory to behave > in all respects like an installed copy of the project. This is not what > the SCM tools are designed for. Er, I don't expect the SCM to behave in all respects like an installed copy of the project. Well, perhaps it would be nice if it did, but where Fossil cannot handle it, file permissions/ownership for example, I also have workarounds, in my case a post-checkout script. Regards, Barry Kauler ___ 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] hidden files on linux support?
On Sat, Dec 3, 2011 at 12:38 PM, Eric wrote: > No it's not up to fossil. But dotfiles are a portability issue, > How on earth are they a portability issue? (Ignoring MS DOS limitations, since it is not a target platform for fossil and.) > they are a *ix thing, and they are meant to be hidden. Dotfiles do not, in and of themselves, mean "hidden" - hiddenness is a _convention_ followed by many, but not all, Unix tools. There is _no way_, at the level of user-space tools, to truly hide a file in a filesystem. Only the filesystem driver can do that. What does "hidden" mean? It means nothing in and of itself on Unix. Windows/FAT has a "hidden" file attribute - Unix does not. What should fossil do about hidden files on Windows where it is > an attribute, not part of the name? > Fossil does not work with file attributes other than (and only after several heated discussions on the topic) +x on Unix because not supporting +x means configure scripts not being executable without the user making them so. +x is, as far as fossil is concerned, an unfortunate special case. There is absolutely no reason why fossil should interpret/translate "leading dot" as e.g. the hidden attribute when checking out files on Windows systems, just as it makes no special attribute changes (other than +x) when checking out such a file on Unix systems, and just as it would mostly certainly not rename the file "foo" with the hidden attribute on Windows to ".foo" when checking out the file on Unix. The dot is part of the name only, not part of the metadata. As someone else pointed out: fossil add * does not see the dotfiles because the SHELL, not fossil, filters them out. The proper way to glob files which contain a leading dot is to use a leading dot in the glob. Whether or not fossil should also include, by default, dotfiles when doing: fossil add . is a philosophical question i will happily punt on (i never add files that way because the risk of adding unwanted/temp files is too great). -- - stephan beal http://wanderinghorse.net/home/stephan/ ___ 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] hidden files on linux support?
On Sat, December 3, 2011 10:56 am, Barry Kauler wrote: >>> fossil add --dotfiles . >>> >> that's exactly what I searched for. Is there a way to make this >> behaviour default for a repository? > > I would very much like this too please. > I am a newcomer to Fossil, was quite surprised that hidden files are > left out by default. Why? What is the definition of "hidden". > Note, my Fossil repo has hidden files, symlinks, binary files, empty > directories, and files/directories with special permissions/ownership! Your project has these things. To the extent that my projects have them, I deal with them with setup, build, and install scripts. I don't actually see why people expect a newly-made checkout (working) directory to behave in all respects like an installed copy of the project. This is not what the SCM tools are designed for. Eric -- ms fnd in a lbry ___ 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] hidden files on linux support?
On Fri, December 2, 2011 11:23 pm, Stephan Beal wrote: > On Sat, Dec 3, 2011 at 12:03 AM, Eric wrote: > >> 1) needed at build or install time, in which case the build and install >> scripts create them >> >> 2) part of my common development environment, in which case they are not >> part of what I am developing and do not belong in its repository > > It's not up to fossil to decide what goes into the repository (with some > minor exceptions, e.g. certain characters aren't allowed in filenames for > portability reasons). No it's not up to fossil. But dotfiles are a portability issue, they are a *ix thing, and they are meant to be hidden. What does "hidden" mean? What should fossil do about hidden files on Windows where it is an attribute, not part of the name? > Some devs enjoy checking in files matching both conditions (1) and > (2). e.g. not all platforms support real build scripts (Windows), in which > case adding them to the repo might be a project requirement. e.g. fossil's > own makefiles are script-generated, but checked in to the repo nonetheless > for build portability reasons. I have no problem with that, the point is that dotfiles are a special case on *ix and need special handling, not because of a file's role in the project, but because it is "hidden". > On a similar note, i personally find it "absolutely insane" to manage > 200MB binary files via source control, but that doesn't invalidate some > peoples' need/desire to do so. That one really needs a different type of tool, but they don't seem to exist because everyone gets away with using an SCM tool - which is fine as long as they understand that it is not the intended use and that they are responsible for any adaptations that turn out to be necessary. Eric -- ms fnd in a lbry ___ 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] hidden files on linux support?
On Fri, December 2, 2011 11:39 pm, Matt Welland wrote: > On Fri, Dec 2, 2011 at 4:03 PM, Eric wrote: > >> On Fri, December 2, 2011 7:26 pm, Stephan Beal wrote: >> > On Fri, Dec 2, 2011 at 8:17 PM, Eric wrote: >> > >> >> Why on earth would you want to? >> >> >> >> I know others have offered suggestions and explanations for how to do >> >> it, >> >> but I would never have a "dotfile" (or a symlink for that matter) in >> a >> >> repository, so I'm really asking about the use-case. >> >> >> >> >> > Think ".gitignore" and friends. Some tools support files like that for >> > holding various metadata (some non-git tools support .gitignore). >> > >> > http://gitready.com/beginner/2009/01/19/ignoring-files.html >> > >> >> Oh, I know about those. But they are one of >> >> 1) needed at build or install time, in which case the build and install >> scripts create them >> >> 2) part of my common development environment, in which case they are not >> part of what I am developing and do not belong in its repository >> > > Do I detect a hint of judgment in your post Eric? Of course. It's what I do, and what I think should be done so I will, from time to time, say so. Others are free to disagree; and to negotiate if we are working together. > Items 1. and 2. are true in your world perhaps but certainly often > not in mine. I lost an hour of my time because fossil silently ignored > dot files that are a required critical part of a process that I moved > from an ancient SCM into fossil. You won't do that again will you? :) It's part of knowing what your tools do and what assumptions they make. For any non-trivial tool, you will sometimes learn the hard way. > Personally I prefer my tools to let me know if i say "add" and they > choose not to do so however the --dotfiles switch suffices. How verbose should a tool be? There will probably always be cases the tool author(s) never even thought of. And is it really the tool anyway? For "fossil add *" on *ix, fossil doesn't know that it is skipping dotfiles, because the shell has already done that. > There are a few interesting arenas where "source" is not C, nor any > other language you are likely to deal with as a "normal" programmer and > yet these arenas can make good use of a tool like fossil and some even > pay pretty dang good and maybe even deserve a bit of respect :) Not arguing with that at all. Eric -- ms fnd in a lbry ___ 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] hidden files on linux support?
>> fossil add --dotfiles . >> > that's exactly what I searched for. Is there a way to make this > behaviour default for a repository? I would very much like this too please. I am a newcomer to Fossil, was quite surprised that hidden files are left out by default. Note, my Fossil repo has hidden files, symlinks, binary files, empty directories, and files/directories with special permissions/ownership! Regards, Barry Kauler ___ 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] hidden files on linux support?
Am Freitag, den 02.12.2011, 11:50 -0700 schrieb Matt Welland: > Perhaps you want: > > fossil add --dotfiles . > Hi Matt, that's exactly what I searched for. Is there a way to make this behaviour default for a repository? ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
