[fossil-users] directory structure
Hi all, There aren't a lot of restrictions on where to name and locate repository files, but I was wondering what the common practices are. On the repository naming, I used to call my repositories projectname.fsl, but the auto-index mode of operation expects them to be called projectname.fossil, so I've been doing that more lately. As for where to put the repository, I typically have one folder dev where all my development work is rooted, then I have the fossil repositories in that folder and the open projects underneath that. However, that means that I have 2 entries in that folder for each project, the repository and the working dir - projectname.fossil and projectname/. Do others handle this differently? I was considering putting all my fossil repositories in some common place and just having the project directories in my development area. That needs an additional path when cloning and opening, but otherwise should be transparent. That is, my current process is: $ cd ~/dev/ $ fossil clone http://whatever/projectname projectname.fossil $ mkdir projectname $ cd projectname $ fossil open ../projectname.fossil So what I'm thinking about is instead: $ cd ~/dev/ $ fossil clone http://whatever/projectname ~/fossil_repos/projectname.fossil $ mkdir projectname $ cd projectname $ fossil open ~/fossil_repos/projectname.fossil Another method I was considering is keeping the repository within the project directory itself (i.e., clone and open in the same directory), but then I'm always wondering if I'm accidentally going to add the repository to itself with fossil add * or the like. Any other thoughts? -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] full-text search for tickets
Hi all,
I put together a quick external script to do full-text searches on
tickets. It's not anything complicated, just creates a sqlite fts table
and dumps all the ticket info into it, which means that it doesn't
update automatically when tickets are updated. Still, I've found it
useful, so I'm sharing it in case anyone else does.
The nice thing is that fossil doesn't care if there are other tables in
the database, so nothing changes from fossil's perspective.
-J
PS: I've included the script as an attachment, if the mailing list
strips that I'll resend or share it somewhere else.
#!/usr/bin/env tclsh8.6
package require sqlite3
set fsl [lindex $argv 0]
set search [lindex $argv 1]
sqlite db $fsl
# set baseurl [db eval {select value from config where name = 'last-sync-url'}]
if {[db eval {select count(*) from sqlite_master where tbl_name =
'ticket_search'}] == 0} {
puts creating index
db eval {
create virtual table if not exists ticket_search using fts4(tkt_uuid,
subsystem, title, comment);
}
}
set count [db eval {
select count(*) from ticket
where tkt_uuid not in (select tkt_uuid from ticket_search)
}]
if {$count 0} {
puts indexing $count new tickets
db eval {
insert into ticket_search
select tkt_uuid, subsystem, title, comment from ticket
where tkt_uuid not in (select tkt_uuid from ticket_search)
}
}
puts scanning
puts [format %12.12s %-15.15s %s Ticket UUID Subsystem Title]
db eval {
select distinct tkt_uuid, subsystem, title from ticket_search where
ticket_search match $search
} row {
# puts [format ${baseurl}info/%12.12s %-15.15s %s $row(tkt_uuid)
$row(subsystem) $row(title)]
puts [format %12.12s %-15.15s %s $row(tkt_uuid) $row(subsystem)
$row(title)]
}
___
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] http-proxy + https
Jan Danielsson wrote: Hello, This has been brought up before, and I've been meaning to look at it, but it suddenly became a little more urgent. Last week I found myself being in a situation of not being able to clone a https repository due to an evil http proxy, and soon afterwards someone I know ran into the same problem at his workplace. I was planning on adding support for https over http-proxy this past weekend, but other things got in the way. I did however take a quick look and noticed that the code currently makes certain assumptions which makes it a little less trivial than it could have been -- so slight rewiring is required. The usual check, to avoid duplicate work: Is anyone else working on this already? Is anyone planning on touching the ssl and/or http-proxy code in the very near future? I recall seeing this bug/patch a while back: http://fossil-scm.org/index.html/tktview?name=e854101c4f But it's really old, so it's probably not going to apply to the current version cleanly. -J ___ 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 Source forge Fossil hosting
Jan Nijtmans wrote: Jeff, this is a very useful recipe that should be documented in the fossil documentation somewhere! Tried it, and only found one obvious minor typo: ssh -t myproject,myu...@shell.sourceforge.net mailto:myu...@shell.sourceforge.netmailto:myu...@shell.sourceforge.net create This should be: ssh -t myuser,myproj...@shell.sourceforge.net mailto:myproj...@shell.sourceforge.netmailto:myu...@shell.sourceforge.net create Argh, I'm always making that mistake. I have aliases I usually use for this, so I misremembered the longhand way. A new fosclipse project is registered now, the related chiselapp repositories moved there and all other steps followed. So, I would expect the following url to lead to the core repository: http://fosclipse.sourceforge.net/projects/fosclipse/cgi-bin/repos/fosclipse-core I tried all kinds of variations for this URL as well, but I don't see anything. Any ideas how I can debug that? What did I do wrong? It depends on the files you created of course, but if you created the repository as /home/project-web/fosclipse/repos/fosclipse-core.fsl and the cgi script as /home/project-web/fosclipse/cgi-bin/fosclipse-core.fsl then your url would be http://fosclipse.sourceforge.net/cgi-bin/fosclipse-core.fsl The projects/fosclipse part of the path is only when you're looking at sourceforge's own app (i.e., http://sourceforge.net/) - my recipe only works on the project web ( http://fosclipse.sourceforge.net/ ) It's also perhaps confusing that my recipe includes two very different files both named myproject.fsl - the actual repository AND the cgi wrapper. It's also unnecessary to have them both named the same, and the setup differs from the fossil docs (which I should have checked first). In any case, the first task for debugging is getting the cgi to run in the first place. What did you name the wrapper script under your cgi-bin directory? Once you're successfully hitting that, you should get some more informative errors from fossil about why it can't find your repository. -J Thanks! Jan Nijtmans ___ 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 Source forge Fossil hosting
Konstantin Khomoutov wrote: On Fri, 29 Mar 2013 09:10:48 -0400 I'd like to point out this is not at all a source forge version. This is just a regular SF project created by someone -- see for yourself [1]. To my knowledge, SF does not provide Fossil hosting. SF doesn't provide it, but it's easy to do yourself. Steps: 0. Create a SF account, SF project, and set up your ssh keys so that you can log into their shell service. 1. connect to the SF shell service, and navigate to the project web directory for your project: $ ssh -t myproject,myu...@shell.sourceforge.net create Welcome to sourceforge! -bash-3.2$ cd /home/project-web/myproject 2. Obtain a fossil binary. Unfortunately the ones from the download page on fossil-scm.org are built against a newer version of linux than SF's servers and so will not run there, but you can build a compatible older version yourself. (Or some kind person could put of a fossil binary that will run on a 2.6.18 kernel). Put that fossil binary in the project-web directory. [get fossil somehow] -bash-3.2$ ./fossil Usage: ./fossil COMMAND ... or: ./fossil help -- for a list of common commands or: ./fossil help COMMMAND -- for help with the named command -bash-3.2$ 3. create a folder for your fossil repository that is writable by the web server. -bash-3.2$ mkdir repo -bash-3.2$ ls -ld repo drwxrwx--x 2 myuser apache 4096 Mar 29 16:45 repo -bash-3.2$ 4. put your fossil repo in that directory, or create a new repo -bash-3.2$ ../fossil new myproject.fsl project-id: 1e70588abb440a6ff839f6897d5397107df3a044 server-id: 1962ad62f3e973014df28323a1c9f59c8b7f6f50 admin-user: myuser (initial password is 08324d) -bash-3.2$ 5. make the repository writable by the web server -bash-3.2$ chmod g+w myproject.fsl -bash-3.2$ 6. create the cgi frontend -bash-3.2$ cd /home/project-web/myproject/cgi-bin -bash-3.2$ cat myproject.fsl #!/usr/bin/env /home/project-web/myproject/fossil repository: /home/project-web/myproject/repo/myproject.fsl ^D bash-3.2$ chmod +x myproject.fsl 7. connect to your new fossil repository http://myproject.sourceforge.net/cgi-bin/myproject.fsl 8. do normal fossil setup tasks - set project name, design, etc. SF has a policy that you should include the sourceforge logo on your project-web hosted pages, so go to your sourceforge project page, select project admin analytics, and go to the Displaying the sourceforge.net logo page; pick the appropriate logo and change the fossil logo in the header setup admin page from div class=logo img src=$baseurl/logo alt=logo brnobr$project_name/nobr /div to div class=logo a href=http://sourceforge.net/projects/myptoject;img src=http://sflogo.sourceforge.net/sflogo.php?group_id=12345678amp;type=16; width=150 height=40 border=0 //a brnobr$project_name/nobr /div (for whichever logo you happened to choose) 9. Set up your project web homepage to point to your fossil repo. -bash-3.2$ cd /home/project-web/myproject/htdocs -bash-3.2$ cat index.php ?php header(Location: http://myproject.sourceforge.net/cgi-bin/myproject.fsl/home;) ? ^D -bash-3.2$ 10. clone your fossil repository from elsewhere, make changes, etc. $ fossil clone http://myproject.sourceforge.net/cgi-bin/myproject.fsl myproject.fsl By the way, my opinion on the matters is that ideally someone would convince any of big players (like SF, advogato, bitbucket, berlios, google code etc) to provide Fossil hosting as part of their existing architecture. Otherwise, I reckon, Fossil hosting will remain a niche activity and will still have zero visibility as it has today. You could try upvoting this ideatorrent post: https://sourceforge.net/apps/ideatorrent/sourceforge/ideatorrent/idea/603/ But I'm they don't use it any more, and feature requests are just done through their forge project: https://sourceforge.net/p/forge/feature-requests/ -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] jump to UUID search box
Someone had mentioned the need for a jump to uuid box in the fossil ui (if you got a uuid from somewhere other than the web ui - 'fossil annotate' for example, or just a link on a different server), so I threw together this cheap javascript hack. Put this snippet in your header (or wherever you want it) to get a 'jump to uuid' box. th1 html form name='uuid' onSubmit='document.location=\$baseurl/info/\+document.forms.uuid.uuid.value; return false;' /th1 Jump to UUID: input type=entry name=uuid size=8 input type=submit value=Go /form You can see/test it on http://chiselapp.com/user/evilotto/repository/web-tools/index Cheers, -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] merging tickets
Hi all, You can merge a single revision/delta into your current branch with -cherrypick. You can attach a single revision to a ticket by mentioning the ticket id (or a prefix of its uuid?) in the checkin comment (I think - the docs I could find weren't very clear on this). And form the ticket view you get a link to checkins associated with the ticket. Can these two functions be combined, so that you could cherrypick all checkins associated with a particular ticket? This seems like it should be easily scriptable, but I can't see how to get the checkins associated with a ticket from the command line. Thanks -J ___ 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] How should Fossil handle this merge conflict...
Local edits being lost seems the wrong thing to do, even if they are recoverable with an undo action - undo doesn't always do what I expect, which is probably user error, but since undo is only one level deep st also seems that if they are not recovered immediately, they would be lost forever. What if an implicit check-in was done to any files that would be affected by the merge (whether deleted or merely edited) imediately before the merge? Local edits would then be a fork preserved in the repository, and undo wouldn't actually be undoing anything, but rather reverting to that forked version. -J Richard Hipp wrote: Suppose you have the trunk branch checked out and you have made changes to file xyz.txt locally, but have not checked them in. Then you do a merge of branch other-branch: fossil merge other-branch The file xyz.txt has been deleted in other-branch. What should fossil's response be? Should it retain the locally edited copy of xyz.txt, or should it delete file xyz.txt? If you have not made any local edits to xyz.txt when you do the merge, then Fossil will delete the file. That seems like the right thing to do. But I'm less clear on what the right thing to do is if you have made local edits. Suggestions are appreciated. Please remember that by delete the file you are not really losing any information. Historical versions of the file remain in the repository forever. And even if your local edits are deleted, they can be recovered using fossil undo. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] backout a merge
Hi all, After you merge in changes from a different branch, but before you check in the merge, is there any way to back out the merge? fossil revert undoes the changes but leaves the files edited, although with no changes. Alternately, is there a way to preview what a merge will do without actually doing the merge? Here's what happens when I try to revert a merge: $ fossil changes $ fossil merge dev2 UPDATE rb $ fossil diff Index: rb === --- rb +++ rb @@ -1,3 +1,3 @@ -the line 1 +that line 1 line 2 line 3 $ fossil revert REVERTED: rb fossil undo is available to undo the changes shown above. $ fossil changes EDITED rb $ fossil diff Index: rb === --- rb +++ rb $ This is fossil version [4a094f46ad] 2010-11-01 18:52:37 UTC Thanks, -J ___ 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] Hosted fossil solution
Richard Hipp wrote: That said, even Fossil requires a host. So if you don't already have a host sitting around (as many people don't) I think such a service would be quite useful. It's easy enough to host a fossil repository on sourceforge, tho it doesn't interoperate with all their other tools. I can post some simple instructions if anyone's interested. -J ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] ticket notifications
Hi all, Is there a way to set up the ticket system to send email notifications when a ticket is created (or changed, etc)? There doesn't appear to be any way in TH1 to run an external command (like sendmail) Alternately, is there a command-line way to list any tickets created in the past X (e.g., 1 day), so that a cronjob could check for new tickets and send mail? Thanks -J ___ 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 GUI for local source tree operations
D. Richard Hipp wrote: I initially set out to design Fossil so that anonymous users on the open internet could commit and the permissions and signing system would be sufficient to keep out malicious content. But I quickly found that such a system is difficult to both implement and use. So I backed up to the traditional model of only giving check-in privileges to people you trust. Is it possible to have some kind of more granular permissions, even on just an advisory basis? For example, setting a users tag on a branch such that only users listed in the tag could checkin changes to that branch. People could still edit the tag or push their changes, but it could give a suggestion of roles and prevent some dumb mistakes. -J Of course in a DVCS, anybody who can clone can also do local check-ins to their private copy of the repository - there is nothing you can do to stop them. But you can stop them from pushing those changes back into official servers. That is what we do at Fossil and SQLite. Any anonymous user can clone the repositories and start checking in whatever they want to their local copies. But they can't push the results back to official Fossil or SQLite servers. Messes are avoided by simply not giving push privileges to anyone who is likely to create a mess. Select your developers carefully, but then trust them to do the right thing. In the (rare) circumstance where a developer goes bad on you, there is alway shunning to clean up the mess. Note that each SQLite server tracks the IP address from which it received each artifact via push. This feature is there to make it easier to track down and shun all artifacts from a single rogue developer. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
