Re: [fossil-users] commit --private for a review before real do, then how to proceed a real commit?
H.C. Chen schrieb: you are content with its state. Then you simply merge your private branch back onto your trunk When being content with the private thread's state, I am standing on the private thread. So, fossil merge trunk-commit-id fossil ci -m Still private Problem!! is still standing on the private thread. I cann't find any merge command option to merge it *back onto* the trunk. Please show me exactly how to do it. Thanks ! Ah ... in Fossil you are merging *from* somewhere *into* the current checkout all the time! If you have a look onto fossil merge --help you will read: Usage: fossil merge ?OPTIONS? VERSION The argument VERSION is a version that should be merged into the current checkout. (...) So that meant, as soon as you are content with you private branch, you have to switch to the trunk (or whatever your target is, via fossil update trunk and then merge your private branch into the trunk via fossil merge private-branch-commit-id . Check the changes, resolve any conflict and if you content with your result, commit it back onto trunk ... That's all about ... Happy fossil'ing, chi :-) ___ 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] Help install fossil as window service
Steeve St-Laurent schrieb: Hi, Hello, I'm trying to install fossil as a window service. i sucessfully created the service with this command sc create fossil binPaht=GoodPath\fossil.exe server hmmm ... I do not know Windows. But you probably misspelled binPaht? Shouldn't this read binPath perhaps? (...) Ciao, chi :-) ___ 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 IS FOSSIL REMOVING ALL MY CODE!
Richard Hipp schrieb: (...) Does anybody have any other suggestions on how to prevent the lose of uncommitted work? Maybe not suggestion to prevent losing of uncommitted work, but I'm thinking about using 'stash' in such situation. Perhaps Fossil could do this automatically. Whenever an 'update' would change any locally modified file, Fossil could stash the changes away first and inform the user. That's sort of what fossil undo does. Except it only stores the most recent change. You are suggesting an auto-stash that keeps backups at each change, and stores them in a visible place such as the stash. An interesting idea... But only if an update would modify local uncommitted changes, I think. So if I commit every time before I update, no auto-stash would be necessary. Would we purge the auto-stash on a commit? Or just let it grow until the user manually purged it? No, I feel it should not purge the auto-stash on commit. It would be safer, if it has to be deleted manually. Then I have explicitely to choose that I do not those changes anymore. Fossil cannot know my intentions. And tracking all of my actions to be sure that the auto-stashed changes were really re-introduced into my working copy would be a ehrm tricky task to implement. What Fossil could do is to warn on every commit I do until those auto-stashes are dropped again (perhaps with asking for permission to proceed with current checkin in face of auto-stashes). Ciao, chi :-) ___ 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 IS FOSSIL REMOVING ALL MY CODE!
Ron Wilson schrieb: On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa g...@atmarama.net wrote: On Sat, 21 May 2011 14:32:34 -0400 Richard Hipp d...@sqlite.org wrote: Does anybody have any other suggestions on how to prevent the lose of uncommitted work? Maybe not suggestion to prevent losing of uncommitted work, but I'm thinking about using 'stash' in such situation. Perhaps Fossil could do this automatically. Whenever an 'update' would change any locally modified file, Fossil could stash the changes away first and inform the user. That way one could apply the stash to the updated working tree dealing with conflicts and such. After all went well the stash may be dropped manually. Then it would be much more difficult to lose local modifcation not committed so far. Doing a fossil update should never delete uncommitted changed files. Zed's post implies this happened. The 'stash first' should protect us here too :-) (...) Just my two cent ... Ciao, chi :-) ___ 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] tags branches after importing from CVS
Joan Picanyol i Puig schrieb: (...) Hello Joan, first you have to understand, that tags in Fossil are what other VCSs call properties. That means, there is the possibility to assign a value to a property/tag if one wants to. Then those properties/tags can be chosen to propagate automatically down the descendants chain of child revisions, or they are only valid for a certain commit only. How is tag cancel supposed to work and how am I supposed verify it? If you chose to cance a tag/property it means, that the tag will not be regarded as associated with that commit anymore. It is still sitting on this commit, but will not apply on it. If the tag had a value, that value is lost afterwards. Furthermore the tag will not any longer propagate to the descendants if it was a propagating tag. Therefore it is also cancelled for the descendants. You can verify this via the 'fossil ui' command, that show you those tags striked out. (...) ** If tagtype is 2 then the tag is being propagated from an ** ancestor node. If tagtype is 0 it means a propagating tag is ** being blocked. Where are the magic tags modified by --raw defined? See above. Looking at the source it seems that --raw merely disables de automatic handling of the sym- prefix for the tagname. Yes! If you create a tag via option --propagate the tag type is propagating. If you issue a fossil tag cancel ... the tag type will be propagation blocked (or tag cancelled) AFAIR ... I'm confused on the existance of branch=branchname vs. sym-branchname. It appears redundant to me... All tags that begin with prefix sym- can be used at command line instead of the SHA1 sum of a commit. So at your example above I could use fossil co branchname because the tag was called sym-branchname. The last commit with that tag applied will be checked out then. The property branch does not contain any sym- prefix and therefore *cannot* being used at command line to select a commit instead of using its SHA1 sum. But as it has assigned a value to it (branch=branchname) Fossil know on which branch the current commit currently resides. If there were no such property, Fossil wouldn't know the current branch, as there could be more than one tag with a sym- prefix prepended -- propagating or not (e.g. release, fix, testing, ...) Best regards and happy Fossiling, chi :-) ___ 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] overwrite file (a=always/y/N)?
Russ Paielli wrote: Sorry if I am being dense, folks, but I keep getting this question when I open fossil: overwrite file (a=always/y/N)? It goes through all of my files with the same question. I have no idea what this means, why it is being asked, or what the correct reply is. Overwrite it with what? Will someone please give me a clue? Thanks. I get this question, if I e.g. close a working copy and then re-open it again. Because 'fossil close' do not delete the files from the working copy, the 'fossil open' afterwards will recognize that -- during checkout -- the actual file being checked out does already exists (not deleted by 'fossil close'). So it will ask you if it is safe to overwrite it with the one currently checked out. Another situation where this could be happen is, if you have file names differ only by upcase/lowcase spelling and are checking out on a filesystem that regard e.g. 'FOO.c' and 'foo.c' as the same filename (e.g. NTFS or HFS+). Does one of this explanation is matching your environment? Best regards, chi. (...) ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Change of marking of privacy for branches ...
Hello, I have a question that is associated with ticket [e29ea5912a] Privacy attribution loss due to de/reconstruct. Currently, information which artifacts are private is stored in a SQL table 'private' whose content cannot be deconstructed or transferred to another repository. A repository that is deconstructed and reconstructed again, lose all information what branches were private in the original repository. Now I am thinking whether it could be a feasible idea to not store privacy information within a separate table, but to simply attach a raw tag 'private' (*not* 'sym-private') to every checkin we would like to mark private (i.e. that should not be sync'd or cloned). Such a raw-tag could survive a deconstruct/reconstruct cycle. And more: we could edit a branch privacy after the fact, if we like. Or we could also allow to 'push' such branches marked as 'private' to e.g. a backup repository. This would allow to backup a large repository via automatic issued push tasks, instead of copying the whole repository ever and ever again ... Would anything speack against such changed behavior to depend a branche's privacy on a raw-tag instead of an entry in a local SQL table within the repository? What is your opinion? Regards, chi. ___ 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] Question about global settings
James Turner wrote: (...) My question is why is autosync and also localauth explicitly set in the local repository upon creation? Couldn't they be treated like the other settings and just have some default in the code base that gets used if locally or globally they are not set? Hopefully this will clear things up. Now I understand better, thank you. I think, you have a reasonable question. Your proposal, though, would have its drawbacks too. I -- for instance -- often take some repositories on a USB stick with me. If the default was not established in creation, working with my repository would depend on the global settings of the user I currently using my repository with. This could be very confusing as well for that use case. But except for this, I do not see any further big drawback at the moment. Perhaps wait whether there are further discussions concerning this thread, and if nothing speaks against this, you could try to open an improvement ticket with your proposal. Except -- of course -- if DRH already rejected it here on the mailing list at that time ... Ciao, chi. ___ 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] Question about global settings
James Turner wrote: Quick question, if I have autosync set to off globally but the repository has it set to on...who wins? If there is no locally defined setting, it takes the global one. If there is a local setting defined, it will beats the global one. From what I see the repository wins, so what does setting it globally get you? That you have not to set it for every new created repository explictly. Only if it divert from your global policy. For me for instance: autosync, localauth and editor are set globally only. Only for a few reository, I did change one or another setting locally. Ciao, chi. ___ 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] Repository in a single file
Stephen De Gabrielle wrote: I took a look at subversion, and it seems to use a single db/filesystem FSFS? I'm guessing the same issues apply? Hmmm ... at least if using the FSFS storage, a repository consists of a lot of files. They can be backed up very comfortably as they are immutable after creation. In the normal case only new files are added during modification of the repository state, AFAIR. So I guess it is not really the same issue as with Fossil. Ciao, chi. (...) ___ 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] Numbered list syntax?
Michael Richter wrote: I don't get it. We never had to number the list ourselves. What was wrong with : Numbered list 0 Number one 0 Number two 0 Number three It gives you a list that looks like: 0. Number one 0. Number two 0. Number three That's not really a numbered list, now, is it? Ahhh ... in my Fossil wiki it gives me: 1. Number one 2. Number two 3. Number three Try for yourself in the Fossil wiki's sandbox ... But pay attention: Every number enclosed in *two* Blanks! Ciao, chi. ___ 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] relocate a repo
Matthias Teege wrote: Moin, I've made a copy (not a clone) of an directory with an open fossil repo. I've made some changes and now tried to commit. Fossil looks for the repo db in the old location and gives me repository does not exist or is in an unreadable directory: ... Is it possible to relocate my working directory without losing my changes? You could do a rm _FOSSIL_ fossil open /my/path/to/the/repository.fsl --keep Important is the '--keep' option; with this your directory contents will not be overwritten by the 'open' command. But you need probably to know the branch and perhaps the revision you were at, as my command given above would try to open against the 'trunk' and there the last version. Better to read the help of the 'open' command first. Ciao, chi :-) (...) ___ 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] Zip files won't unzip on OS X
Will Duquette wrote: Anonymous can clone it, according to the Users page. I've not tried that myself. Hmmm ... if I try, fossil means, that anonymous have no rights to clone the repository. If you look onto the User page, what password user anonymous posses? Perhaps it is some hex value, then cloning is not very easy ;-) In the past, if a repository was new created, every anonymous got the password 'anonymous'. But since some time, every new created repository get a random password for anonymous. If I do not know this, I cannot clone the repos despite the permission. If this is the case, you would have either to change and publish the anonymous password for users that would like to clone (the login password for anonymous will still be generated automatically to be different for every login), or you would have to allow user nobody to clone ... Ciao, chi. (...) ___ 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] Zip files won't unzip on OS X
Will Duquette wrote: I thought that might be the case, but I wasn't sure. I've set it up so that nobody can clone. Alternatively, you can log in as anonymous and use the Zip Archive link on the Leaf page. Or you can download glue.kit. Thank you, now cloning worked out :-) Thank you, chi. (...) ___ 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] Zip files won't unzip on OS X
Will Duquette wrote: - hide quoted text - Hello Will, I've got a fossil repository at http://wjduquette.com/projects/robbie.cgi. If I download a Zip Archive for a leaf, the OS X Archive Utility won't unzip it; it says that it's corrupted. The command-line unzip command unzips it just fine. jepp, this was an issue for Fossil for a longt time (ticket 923a912309). Fortunately this problem was solved with revision d78835d2ff -- commited 18-Oct-2009. Unfortunately you Fossil binary (revision 37f295c310) from 21-Sep-2009 is too old and therefore does not contain the fix. So if you upgrade your binary (and probably fossil rebuild the repository) the problem should vanish ... BTW: Does you also host your excellent Notebook and Snit with Fossil? (...) Best regards, chi ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
