Hi Dave,
On 22/11/17 15:27, David Mason wrote: > Also as a mere fossil user, I would find it useful if fossil could > respond to a git client and serve files. I use Pharo, which is working > toward integrated support for git, but I'd much rather trust my bits > to Fossil. While the Fossil UI is nice, I see much less value in using > a local Fossil to access a remote git/hg repo. I'm also a Pharo User. I think that is important let a Fossil be employed by Git clients, but I'm dubious over making Fossil a client for any other main DVCS out there. Fossil's web interface has been pretty useful in our workshops on data activism and visualization over there to teach newbies (like myself) about DVCS. BTW I understand that this is not a discussion on the capability of more expert users and devs to implement the idea, but about how it impacts the wider community. I for example didn't understand the original discussion about ".fossil" because I thought it was (only) about shallow copies instead of the default behavior for making a single step clone and open, like Git. Making Fossil a client of majors DVCS means learning a lot of variations on what happens to make it behave like others. Of course, we need to see where it makes sense, but the context/motivation of that discussion will be difficult and sometimes will scape for those of us that chose Fossil because it was like itself, instead of because was like others. Support for multiple VCS formats is clear as a server, but the nuances and complexities code/learning wise it will introduce as a client should be considered for those of us that like/choose Fossil because of its simplicity. > > 2) Allow me to designate any file in the directory structure as > unversioned. The current unversioning model does not work well for > me. It essentially is equivalent to Dropbox. I am working with > PharoJS which produces Javascript files from Smalltalk code. I want my > source code and the generated code in Fossil. I also have movies and > image files that I want in particular places. I realize the Fossil > model is to be able to revert to exactly the state of things on > such-and-such a date, including the versions of movies and images as > they were, but I - at least - very rarely care that images and movies > are exactly as they were, I'd almost always be perfectly happy using > the current version. An ideal alternative would be to have versioned > files but where it only kept snapshots of versions I explicitly asked > for, otherwise it would just update the current version. I'm still trying to understand unversioned files. What I would like is to make them sync automatically when the rest of the repo is synchronized (via sync or commit). Something like if the unversioned file changed locally, just send the new version to the remote repo. If that is the intended behavior, there is something in the workflow I'm missing. > > Thanks for fossil! > Yes. Thanks a lot! Offray _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
