On Mon, Oct 27, 2014 at 12:48 PM, Tony Papadimitriou <to...@acm.org> wrote:
> OK, maybe I have a misunderstanding of the need for close. What is it > used for? The claim by Stephan Beal that he hasn’t closed a repo more than > 5 times over many years makes me wonder why is there even a CLOSE command? > All close does is: a) removes the .fslckout resp. _FOSSIL_ file from the checkout b) it should (IMO, if it doesn't already) remove the checkout from the "all" list (kept in the global config db). Thinking over it now, i confused repos and checkouts with regard to the "all" list - when closing a checkout, the _checkout_, not the repo, should (IMO) be removed from the "all" list. Primarily 'close' is only used to remove the "fossil crud" from the tree (the checkout db file), e.g. before ZIPping it up for distribution by a client (but fossil supports zip/tar out of the box, so 'close' has even fewer real uses). > In my case, there is no server used, because this is private work that I > cannot trust to be placed on any public server since I do not want anyone > to have access to it (and by anyone I include the owner of the public > server). I have thought about setting up a server on one of the two > machines (home or office) but that would require one of these computers to > be always on, which again I would rather not have. So, in my case, my only > alternative is to move the fossil file from computer to computer – so that > the ‘master’ relocates all the time between two points. And, proper > procedure for most applications would be to close a file, transfer it, and > then re-open it. But, maybe fossil is more lenient... I don’t know. > If you are working by manually copying the repo dbs, then "close" is probably a good thing to do, to avoid any side effects with blob IDs being different between your checkout copies. That's an unusual use case for Fossil, though - most users have a central copy, either available via CGI, on a network drive, or similar (that said: network drives are not recommended for this purpose - there are historically many problems involving file locking over network shares). If you have the option to host CGI scripts, i can strongly recommend moving the repo to your CGI hoster and accessing it over the network. Most internet providers offer CGI script support in their package, so if you have a hoster already then you likely have this option. So, are you saying, that if I keep both repo versions (work and home) open > all the time, and simply copy over (from the backup) the related fossil > files, there won’t be any corruption on either site? > Better not do that. If you really are copying around the repo dbs, it's safest (IMO) to close them before copying them around. Not strictly required, but not a bad idea. And, I suppose instead of open (at the start of the day), I should be doing > what exactly? FOSSIL REV to update the current checkout from the just > updated FOSSIL file which would appear like a revert on the other side? > In the normal case you'd do: fossil update But in your case i think that 'open' is the "right" approach (for a given definition of "right" ;). > Or, an UPDATE? And, what if I’m on different branches? Is this > guaranteed to work correctly without creating any unpleasant side effects, > from simple forks, etc., to the most serious of which would be a corruption > of the repo and loss of work (and not only one day’s)? > fossil update BRANCH will merge as appropriate. Using open/close, i believe you are far more at risk for data loss than you would be using 'update.' > OK, maybe I do not need the functionality I asked for but can someone > explain what would be the equivalent work flow between two different > machines where there is no common server, and the FOSSIL file is at any > moment replaced with a new file (from the other machine?) Currently, my > process is this: > i would argue that that's not a use case fossil targets (or not a common setup). > LOOP: > FOSSIL OPEN > ... code changes ... > FOSSIL COMMIT > FOSSIL CLOSE > > transfer repo file to other machine, and copy it over the previous version > goto LOOP > If you _must_ copy the repo files around, then the above loop is essentially the right way to do it (again, for a given definition of "right" ;). -- ----- stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal "Freedom is sloppy. But since tyranny's the only guaranteed byproduct of those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
_______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
