Re: [fossil-users] "commit --private" for a review before real do, then how to proceed a real commit?
Hello, H.C. Chen schrieb: > I learned from a tutorial or somewhere else that use --private option to > have a chance to review my commit on local computer. Good idea. But if > everything ok then how to commit it up to the server? My method is : > > fossil close -f <= -f needed because there are unsaved checkout > according to the warning message. > fossil open project.fossil <=== go back to the last > sync'ed point. > fossil ci -m "message"< checkin again formally > > This process works but it smells bad. What's the correct way to bring a > private thread back to the trunk? this all is a bit clumsy. You should simply work with your private branch until you are content with its state. Then you simply merge your private branch back onto your "trunk". Sync it and done ... 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] "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 > 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 . 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] 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
Re: [fossil-users] Zip files won't unzip on OS X
Will Duquette wrote: > Chi, > Hello Will, > Thanks for the word about the bug fix. I'll see about updating to the > latest Fossil binary; I'd been putting it off until there was some > compelling reason. :-) > I am lucky, that my answer was helpful :-) (...) > Some of the Notebook infrastructure code is available at > http://wjduquette.com/projects/glue.cgi , though, including a variant > of the Notebook 2 markup and renderer. And that *is* in Fossil. Nice! :-) Is it allowed to clone that repository? 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] 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 --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] 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] tree checksum does not match
D. Richard Hipp wrote: (...) > Can you send me your repository and a tarball of your checkout via > private email so that I can try to reproduce the problem here? > By looking at the typescript, I would guess, that the file "/home/erl/putitgetit/manifest" could be the culprit. If his directory contains an own file "manifest" this will conflict with the one by Fossil! In the past I had the same error, that if I have a file "manifest" (or "Manifest" on e.g. MacOS/X) Fossil will recognize and remember my file, overwrite it with its own "manifest" and then complain about checksum mismatch ... 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] fossil concepts (a newbie question).
pasqualinoferrentino-fos...@yahoo.it wrote: > Sorry I am a newbie for fossil; until now I have used git and > mercurial. > Welcome to Fossil then ... > I have a doubt regarding the sentence: > > "A fossil repository is a 'unordered bag' of artifacts". > > In mercurial and in git the emphasys is on the "graph" > concept... every object (for example in git a commit or a blob or a > tag) is related to others... > > In any case also in fossil an artifact is related to others... so for > me (sorry for the naive question) in any case also in fossil we have a > graph, only that it is "hidden" inside the artifact format and not > "external" in the repository "metadata". > > Could it be correct as a comment? > I would say, you are right! The artifacts are somehow related to each other, but this relationship is contained in the artifacts itself. The repository, however, is only a container (unordered bag) holding these artifacts. You could try to do a fossil deconstruct deconstructed within a checkout. This will create a directory 'deconstructed' with all artifacts written out in readable format sorted by, IIRC, the first two character of the artifact's sha1-id. With fossil reconstruct repos.fsl deconstructed Fossil should be able to re-create 'repos.fsl' out from the artifacts contained in 'deconstructed'. But I believe, that Fossil do held some further metadata also contained in the artifacts in extra tables for performance reasons (kind of cache). These tables can easily be repopulated at will with fossil rebuild if necessary (i.e. the database format has changed). :-) (...) 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] 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] 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
[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] overwrite (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 (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
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] WHY IS FOSSIL REMOVING ALL MY CODE!
Ron Wilson schrieb: > On Sat, May 21, 2011 at 4:29 PM, Gour-Gadadhara Dasa > wrote: > >> On Sat, 21 May 2011 14:32:34 -0400 >> Richard Hipp 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] 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] 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
