Re: [fossil-users] Building a new repository with the same users and passwords as an existing repository.
On Tue, Sep 11, 2012 at 5:43 PM, Richard Hipp wrote: > > > On Tue, Sep 11, 2012 at 7:25 PM, Clive Hayward > wrote: >> >> With fossil version 1.23 [957b17af58], I am serving multiple >> repositories using the directory-of-repository feature outlined by drh >> in >> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01486.html >> >> I wish to create new repositories using the same usernames, passwords >> and permissions as a master repository. I can create a new repository >> and have web access with the same repository by turning on the >> group-login feature but this doesn't add the users so they cannot >> clone a repository. >> >> If I export then import the users configuration from the master >> repository to the new repository. The users exist but the passwords >> need to be updated via the web-interface before they can clone the >> repository. > > > If you export/import the users, then set group-login, you should be able to > login to the new repo using the password on the old one. Is that not > working for you? I am able to login in to the web site no problem. But cannot clone the repository. Here is the result of a clone command on a new repository with login group turned on and user configuration imported: Bytes Cards Artifacts Deltas Sent: 53 1 0 0 Received: 152 3 0 0 Sent: 68 2 0 0 Error: login failed Received: 52 1 0 0 Sent: 43 0 0 0 Error: login failed Received: 52 1 0 0 Total network traffic: 956 bytes sent, 991 bytes received fossil: server returned an error - clone aborted > > Unfortunately, the password hash used by Fossil includes the project code, > so different repositories have different hashes even if the actual password > text is the same. (This is a security feature.) > >> >> >> How can I copy the configuration users and passwords and membership in >> group-login from an existing repository? >> >> Also, shouldn't the group-login information be part of the >> configuration export or accessible from the settings on the command >> line? > > > I don't think group-login should be part of configuration export/import. > Configuration export/import is used to move configurations from one > installation to another. But at each installation, you (or at least I) > typically have a different set of repos and so the group-login information > no longer makes sense. > >> >> >> Regards, >> >> Clive Hayward >> ___ >> fossil-users mailing list >> fossil-users@lists.fossil-scm.org >> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > > > > > -- > D. Richard Hipp > d...@sqlite.org Thanks -- Clive Hayward ___ 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] Building a new repository with the same users and passwords as an existing repository.
On Tue, Sep 11, 2012 at 7:25 PM, Clive Hayward wrote: > With fossil version 1.23 [957b17af58], I am serving multiple > repositories using the directory-of-repository feature outlined by drh > in > http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01486.html > > I wish to create new repositories using the same usernames, passwords > and permissions as a master repository. I can create a new repository > and have web access with the same repository by turning on the > group-login feature but this doesn't add the users so they cannot > clone a repository. > > If I export then import the users configuration from the master > repository to the new repository. The users exist but the passwords > need to be updated via the web-interface before they can clone the > repository. > If you export/import the users, then set group-login, you should be able to login to the new repo using the password on the old one. Is that not working for you? Unfortunately, the password hash used by Fossil includes the project code, so different repositories have different hashes even if the actual password text is the same. (This is a security feature.) > > How can I copy the configuration users and passwords and membership in > group-login from an existing repository? > > Also, shouldn't the group-login information be part of the > configuration export or accessible from the settings on the command > line? > I don't think group-login should be part of configuration export/import. Configuration export/import is used to move configurations from one installation to another. But at each installation, you (or at least I) typically have a different set of repos and so the group-login information no longer makes sense. > > Regards, > > Clive Hayward > ___ > fossil-users mailing list > fossil-users@lists.fossil-scm.org > http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users > -- D. Richard Hipp d...@sqlite.org ___ 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] Please make shunning a first class feature.
tada! That worked! Question: How come I cannot use fossil shun from a command line? I can only shun from the ui? That makes it difficult to automate if there are hundreds of files to shun. :( Thanks for fossil. On Tue, Sep 11, 2012 at 6:44 PM, Richard Hipp wrote: > > > On Tue, Sep 11, 2012 at 6:22 PM, wrote: >> >> Ok, that removes the file from display, but the size of my repo has >> been permanently grown by the unwanted large file. >> Is that by design? > > > Try "fossil rebuild --vacuum" and let us know if that fixes it. > >> >> I am right back at the beginning of this post. >> What if I or some other developer or some virus added ~../*.* ? >> Would I/Should I be forever saddled with the new size of my repo? >> >> Wait! I ran a vacuum from within SQLiteExpert and my repo is back to >> its original size! >> >> I know someone mentioned vacuum back many replies. But that did not >> work on my earlier and real repo because I had shunned the commit >> artifact, not the file in question. >> >> So now I get it. >> 1. Shun the file(s) artifacts. >> 2. Rebuild. >> 3. Vacuum. >> >> Thanks! >> >> On Tue, Sep 11, 2012 at 4:13 PM, Richard Hipp wrote: >> > >> > >> > On Tue, Sep 11, 2012 at 3:51 PM, wrote: >> >> >> >> Ok, >> >> Tried all previous suggestions and no go. >> >> Had a chance to do something very simple, but my experience was the >> >> same. >> >> I add a single LARGE file to my repo. >> >> I commit. >> >> I delete that LARGE file. >> >> I commit. >> >> I rebuild. >> >> The repo file size still contains the LARGE file in the blob table. >> >> Can I delete the offending blob record and recover my original repo >> >> file >> >> size? >> > >> > >> > Find the SHA1 hash of the large file. You can probably do this doing >> > "fossil ui" and looking under the "Files" menu. >> > >> > Shun just that one SHA1. Do *not* try to shun any other checkins or >> > other >> > files. Just the one file you want to get rid of. >> > >> > After shunning, run rebuild to permanently delete the file. >> > >> > >> > >> > -- >> > D. Richard Hipp >> > d...@sqlite.org >> > >> > ___ >> > 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 > > > > > -- > D. Richard Hipp > d...@sqlite.org > > ___ > 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
[fossil-users] Building a new repository with the same users and passwords as an existing repository.
With fossil version 1.23 [957b17af58], I am serving multiple repositories using the directory-of-repository feature outlined by drh in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg01486.html I wish to create new repositories using the same usernames, passwords and permissions as a master repository. I can create a new repository and have web access with the same repository by turning on the group-login feature but this doesn't add the users so they cannot clone a repository. If I export then import the users configuration from the master repository to the new repository. The users exist but the passwords need to be updated via the web-interface before they can clone the repository. How can I copy the configuration users and passwords and membership in group-login from an existing repository? Also, shouldn't the group-login information be part of the configuration export or accessible from the settings on the command line? Regards, Clive Hayward ___ 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] Please make shunning a first class feature.
On Tue, Sep 11, 2012 at 6:22 PM, wrote: > Ok, that removes the file from display, but the size of my repo has > been permanently grown by the unwanted large file. > Is that by design? > Try "fossil rebuild --vacuum" and let us know if that fixes it. > I am right back at the beginning of this post. > What if I or some other developer or some virus added ~../*.* ? > Would I/Should I be forever saddled with the new size of my repo? > > Wait! I ran a vacuum from within SQLiteExpert and my repo is back to > its original size! > > I know someone mentioned vacuum back many replies. But that did not > work on my earlier and real repo because I had shunned the commit > artifact, not the file in question. > > So now I get it. > 1. Shun the file(s) artifacts. > 2. Rebuild. > 3. Vacuum. > > Thanks! > > On Tue, Sep 11, 2012 at 4:13 PM, Richard Hipp wrote: > > > > > > On Tue, Sep 11, 2012 at 3:51 PM, wrote: > >> > >> Ok, > >> Tried all previous suggestions and no go. > >> Had a chance to do something very simple, but my experience was the > same. > >> I add a single LARGE file to my repo. > >> I commit. > >> I delete that LARGE file. > >> I commit. > >> I rebuild. > >> The repo file size still contains the LARGE file in the blob table. > >> Can I delete the offending blob record and recover my original repo file > >> size? > > > > > > Find the SHA1 hash of the large file. You can probably do this doing > > "fossil ui" and looking under the "Files" menu. > > > > Shun just that one SHA1. Do *not* try to shun any other checkins or > other > > files. Just the one file you want to get rid of. > > > > After shunning, run rebuild to permanently delete the file. > > > > > > > > -- > > D. Richard Hipp > > d...@sqlite.org > > > > ___ > > 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 > -- D. Richard Hipp d...@sqlite.org ___ 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] Please make shunning a first class feature.
Ok, that removes the file from display, but the size of my repo has been permanently grown by the unwanted large file. Is that by design? I am right back at the beginning of this post. What if I or some other developer or some virus added ~../*.* ? Would I/Should I be forever saddled with the new size of my repo? Wait! I ran a vacuum from within SQLiteExpert and my repo is back to its original size! I know someone mentioned vacuum back many replies. But that did not work on my earlier and real repo because I had shunned the commit artifact, not the file in question. So now I get it. 1. Shun the file(s) artifacts. 2. Rebuild. 3. Vacuum. Thanks! On Tue, Sep 11, 2012 at 4:13 PM, Richard Hipp wrote: > > > On Tue, Sep 11, 2012 at 3:51 PM, wrote: >> >> Ok, >> Tried all previous suggestions and no go. >> Had a chance to do something very simple, but my experience was the same. >> I add a single LARGE file to my repo. >> I commit. >> I delete that LARGE file. >> I commit. >> I rebuild. >> The repo file size still contains the LARGE file in the blob table. >> Can I delete the offending blob record and recover my original repo file >> size? > > > Find the SHA1 hash of the large file. You can probably do this doing > "fossil ui" and looking under the "Files" menu. > > Shun just that one SHA1. Do *not* try to shun any other checkins or other > files. Just the one file you want to get rid of. > > After shunning, run rebuild to permanently delete the file. > > > > -- > D. Richard Hipp > d...@sqlite.org > > ___ > 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] Please make shunning a first class feature.
On Tue, Sep 11, 2012 at 3:51 PM, wrote: > Ok, > Tried all previous suggestions and no go. > Had a chance to do something very simple, but my experience was the same. > I add a single LARGE file to my repo. > I commit. > I delete that LARGE file. > I commit. > I rebuild. > The repo file size still contains the LARGE file in the blob table. > Can I delete the offending blob record and recover my original repo file > size? > Find the SHA1 hash of the large file. You can probably do this doing "fossil ui" and looking under the "Files" menu. Shun just that one SHA1. Do *not* try to shun any other checkins or other files. Just the one file you want to get rid of. After shunning, run rebuild to permanently delete the file. -- D. Richard Hipp d...@sqlite.org ___ 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] Please make shunning a first class feature.
Ok, Tried all previous suggestions and no go. Had a chance to do something very simple, but my experience was the same. I add a single LARGE file to my repo. I commit. I delete that LARGE file. I commit. I rebuild. The repo file size still contains the LARGE file in the blob table. Can I delete the offending blob record and recover my original repo file size? Notice, I did not attempt shunning. ;) I apologize if this is overkill, but I still do not get the "design" of unwanted large files and no oops factor to remove them entirely. Thanks for your help. > On Sun, Sep 2, 2012 at 3:36 PM, Kevin Quick wrote: >> I'm not sure if you are saying you no longer have the list of filenames or >> you no longer have the uuid's of those files to shun. >> >> If you no longer have the list of filenames, you can obtain the full list >> from >> >> $ fossil sqlite >> sqlite> .output filenames.txt >> sqlite> select name from filename >> >> This will list ALL files in your database. Remove those you don't wish to >> shun. If you have already shunned the manifest artifacts for the commits, >> and it is not easy to otherwise identify files which should and should not >> belong, you can check for files which are not claimed by any manifests. >> This assumes the files are not named as attachments to tickets or have other >> relationships. Try: >> >> $ for F in $(cat filenames.txt); do fossil finfo $F > /dev/null || echo $F ; >> done >> >> To get the uuid of a file, use fossil's sha1sum: >> >> $ cat filenames.txt | xargs -n1 fossil sha1sum >> >> If you use any of the above to modify your database, I strongly recommend >> making a copy first, as I have not verified that the results of the above >> are 100% safe with respect to shunned/unshunned entries. It's also worth >> noting that a long shun list may adversely affect all future sync and commit >> operations. >> >> -KQ >> >> >> On Thu, 30 Aug 2012 14:48:48 -0700, wrote: >> >>> Ok, this is definitely a case of "if I knew then what I know now" I >>> could proceed as you say. >>> The problem is I read the shunning instructions and did not see >>> mention of possible orphaning of my files. >>> Once I shunned the artifacts that triggered the file additions >>> (thought it made sense), I was toast. >>> Since, there was no longer a file list to peruse :( >>> No problem now. I guess I learn best by touching the hot stove top. >>> >>> On Thu, Aug 30, 2012 at 5:40 PM, Ron Wilson wrote: On 8/30/12, sky5w...@gmail.com wrote: > > Actually, it was hundreds of files that were added recursively with > ..\*.* > I am back to sanity now, but I have not heard an adequate response for > such a simple mistake? > Knowing now that shunning was NOT the correct action in my case. > I ask simply, what should I have done? > Delete individual file artifacts or could I delete them en masse? Doing this away from my development PC, so just giving a "high level" procedure. Get a file list (name and UUID) from the manifest and remove any files you want to keep. Save the list. Using your favorite scripting language, run a loop that reads an entry from your list, invokes fossil to shun that file, then repeat for each entry in the list. ___ 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 >> >> >> >> -- >> -KQ ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Timeline paging
Not critical at all, but when paging the timeline using the "older" button, the last event on the current page is also the first event on the next page. I am curious if this intentional , an oversight or just was easier to do this way as it doesn't really make a difference? -- ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
