Re: [fossil-users] Stash with renames
On Tue, Jul 03, 2012 at 10:35:36PM +0200, Stephan Beal wrote: On Tue, Jul 3, 2012 at 12:20 PM, Lluís Batlle i Rossell vi...@viric.namewrote: here 'fossil stash' behaved weird, if I had done 'fossil mv' operations. The renames remain in the 'fossil status' after stash, and it also caused a revert of all files in my repository; at elast that's what the console log said. Maybe 'fossil stash' should handle better the renames situation? It looks a bit broken. Sorry, did this happen on a save or apply/pop operation? Hello Stephan, in a save operation. Can you reproduce it? ___ 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] Merging with renames (new directories)
On Tue, Jul 03, 2012 at 10:47:51PM +0200, Stephan Beal wrote: On Tue, Jul 3, 2012 at 2:49 PM, Lluís Batlle i Rossell vi...@viric.namewrote: Stracing, it shows it's a open(...,O_CREAT,...) call failing with ENOENT. Have you got the fossil function name which triggered that? open() is called somewhere deeper down than merge.c, and it's not obvious to me where that's being triggered. Was it perhaps merge.c:380 (vfile_to_disk())? My guess is that the bug is at vfile.c:311. We have a routine for creating dirs (file_mkdir()), but i don't see a recursive one (equivalent of mkdir -p). Before i add such a beast, do any of you know if we already have such a routine? The only missing directory was the last /lv, so I don't think it's about a lack of recursive mkdir. But I've not investigated further. Thank you Stephan! ___ 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] A counter in the ticket name
On Fri, Jun 15, 2012 at 7:06 AM, Jacek Cała jacek.c...@gmail.com wrote: Right. I tend to forget about the distributed aspect of fossil as I mostly work with the centralized setup. On the other hand, you could give each instance its own prefix, then all the ticket numbers would be unique. This is a lot of hastle, but sometimes these hastles are necessary to get management to agree. FYI, there are still managers who will go to the hastle of maintaining issues with a spreadsheet. This is simple and easy for them to understand despite all the manual work of keeping the spreadsheet organized. ___ 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] A counter in the ticket name
On Wed, Jul 4, 2012 at 3:09 AM, Ron Wilson ronw.m...@gmail.com wrote: On Fri, Jun 15, 2012 at 7:06 AM, Jacek Cała jacek.c...@gmail.com wrote: Right. I tend to forget about the distributed aspect of fossil as I mostly work with the centralized setup. On the other hand, you could give each instance its own prefix, then all the ticket numbers would be unique. You'd still need a centralized authority to assign the prefixes. This is a lot of hastle, but sometimes these hastles are necessary to get management to agree. FYI, there are still managers who will go to the hastle of maintaining issues with a spreadsheet. This is simple and easy for them to understand despite all the manual work of keeping the spreadsheet organized. ___ 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] Stash with renames
Hi! I didn't find the problem last night but will look at it again tonight. - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal On Jul 4, 2012 8:49 AM, Lluís Batlle i Rossell vi...@viric.name wrote: On Tue, Jul 03, 2012 at 10:35:36PM +0200, Stephan Beal wrote: On Tue, Jul 3, 2012 at 12:20 PM, Lluís Batlle i Rossell vi...@viric.namewrote: here 'fossil stash' behaved weird, if I had done 'fossil mv' operations. The renames remain in the 'fossil status' after stash, and it also caused a revert of all files in my repository; at elast that's what the console log said. Maybe 'fossil stash' should handle better the renames situation? It looks a bit broken. Sorry, did this happen on a save or apply/pop operation? Hello Stephan, in a save operation. Can you reproduce it? ___ 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] A counter in the ticket name
Alternatively, if prefixes (or better suffixes) are attached when cloning, you wouldn't need that. Say my master/primary repo has prefix '1', so when I clone from it my repo would get from the master 1.1 for the first time and 1.N for the n-th time. When someone clones from my 1.1 repo -- exactly the same 1.1.N. I believe the prefixes wouldn't grow that much because most of the time users would clone from the master/primary repo. Cheers, Jacek 2012/7/4 Richard Hipp d...@sqlite.org: On Wed, Jul 4, 2012 at 3:09 AM, Ron Wilson ronw.m...@gmail.com wrote: On Fri, Jun 15, 2012 at 7:06 AM, Jacek Cała jacek.c...@gmail.com wrote: Right. I tend to forget about the distributed aspect of fossil as I mostly work with the centralized setup. On the other hand, you could give each instance its own prefix, then all the ticket numbers would be unique. You'd still need a centralized authority to assign the prefixes. This is a lot of hastle, but sometimes these hastles are necessary to get management to agree. FYI, there are still managers who will go to the hastle of maintaining issues with a spreadsheet. This is simple and easy for them to understand despite all the manual work of keeping the spreadsheet organized. ___ 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
Re: [fossil-users] Postmortum: DRH in Munich
An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself RR 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what ideas others can derive from the descriptions above. i unfortunately failed to take any pictures except one of the whiteboard. :/ We would love to hear your thoughts/elaborations on the above ideas. Happy Hacking! PS: Please pardon my brevity and typing mistakes - i'm on a tablet. ___ 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
Re: [fossil-users] Postmortum: DRH in Munich
On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself I think this can be achieved simply allowing multiple new ticket pages, instead of only one. Different new ticket pages could set a table field to specific values, and then multiple reports could filter one or another. Regards, Lluís. 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what ideas others can derive from the descriptions above. i unfortunately failed to take any pictures except one of the whiteboard. :/ We would love to hear your
Re: [fossil-users] Postmortum: DRH in Munich
No. I mean that every list would have a different table schema with different fields. RR 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself I think this can be achieved simply allowing multiple new ticket pages, instead of only one. Different new ticket pages could set a table field to specific values, and then multiple reports could filter one or another. Regards, Lluís. 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what
Re: [fossil-users] Postmortum: DRH in Munich
On Wed, Jul 04, 2012 at 10:18:10AM +0200, Ramon Ribó wrote: No. I mean that every list would have a different table schema with different fields. Ah, then I don't understand what would be the advantage of different tables, over a single table with all the fields required. Atentament, Lluís. 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself I think this can be achieved simply allowing multiple new ticket pages, instead of only one. Different new ticket pages could set a table field to specific values, and then multiple reports could filter one or another. Regards, Lluís. 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down,
Re: [fossil-users] Postmortum: DRH in Munich
Short on time, just a few terse comments. * Stephan Beal sgb...@googlemail.com [20120703 21:37]: - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. Sounds great, as long as it is not a requirement (either in fossil nor in the client). I guess the wiki markup issue is a done deal then? - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. This would be great if it enabled keyword based tagging for later search. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! This sounds like a wide open door for XSS attacks. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). I smell AOLServer... keep up the good work -- pica ___ 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] Postmortum: DRH in Munich
I think that it is clear: different list - different data requirements - different table fields RR 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:18:10AM +0200, Ramon Ribó wrote: No. I mean that every list would have a different table schema with different fields. Ah, then I don't understand what would be the advantage of different tables, over a single table with all the fields required. Atentament, Lluís. 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself I think this can be achieved simply allowing multiple new ticket pages, instead of only one. Different new ticket pages could set a table field to specific values, and then multiple reports could filter one or another. Regards, Lluís. 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH
Re: [fossil-users] Postmortum: DRH in Munich
On Wed, Jul 04, 2012 at 10:48:54AM +0200, Ramon Ribó wrote: I think that it is clear: different list - different data requirements - different table fields Well, I understand that different tables can provide more speed and better storage efficiency, but I don't understand what functionality different tables provide, that a single table does not provide. 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:18:10AM +0200, Ramon Ribó wrote: No. I mean that every list would have a different table schema with different fields. Ah, then I don't understand what would be the advantage of different tables, over a single table with all the fields required. Atentament, Lluís. 2012/7/4 Lluís Batlle i Rossell vi...@viric.name: On Wed, Jul 04, 2012 at 10:00:52AM +0200, Ramon Ribó wrote: An interesting new capability for fossil could be the following: That it allowed to have more than one tickets list, with different tables and reports in every list. This could have several advantages: 1- Keep a completely separated list for bugs and for new features, for example 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself I think this can be achieved simply allowing multiple new ticket pages, instead of only one. Different new ticket pages could set a table field to specific values, and then multiple reports could filter one or another. Regards, Lluís. 2012/7/3 Stephan Beal sgb...@googlemail.com: Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed
Re: [fossil-users] Postmortum: DRH in Munich
Hi, all! About 5 minutes ago i got home from the all-day meeting with list members Richard (DRH), Bernie, and Gary (what are the odds - the meeting is in Germany and 3 of us 4 carry American passports), and now i've got a small hill of notes scribbled on the back of business cards and yellow sticky notes... Wow, what a day. We didn't actually get around to hacking. Rather, we had an 11-hour series of discussions, starting off with an introduction to Fossil (for the benefit of colleagues of mine who dropped in and as a practice run for DRH's presentation this coming Sunday at a TCL conference). We discussed areas for improvement and came up with some cool new TODOs, none of which either he or i will get a chance to work on anytime soon :/. Hi List, I would just like to add my thanks to Richard, and Stephan for the extensive investment in care and attention to help bring newbies up to speed. Serving considerable know-how and experience; they made the day invaluable for use of Fossil, SQLite and also general hacking. Their careful, individual attention to the questions posed; made the day, and provided a wealth of valuable knowledge and experience. Thanks- Gary Some of the ideas we tossed around as TODOs include (@Bernie/Gary/Richard: please ammend if i have left something out): - Mozilla's RTF editor as a wysiwyg wiki (possibly embedded docs?) editor. We looked closely at this and it this will not be nearly as much work as i first anticipated, but we will have to munge the output just a tiny bit to suit or needs. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! - We might (might!) use jQuery simplify the client-side implementations. This would include a new config option which specifies whether an embedded copy of jquery should be served or a copy from e.g. a Google CDN (offline usage requires an embedded copy). - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original idea was to use this as a new layout mechanism for the site, but we think that this could possibly be used to reimplement some of the current static pages . Part of this would include a templating mechanism. The pages could have security restrictions and could be flagged as syncable/clonable (or not) by the site admin (only admin users would be able to create/edit such pages). A logical extension of this would be to build up snippets/widgets which users can use to customize their pages (e.g. embedding a mini-timeline overview in their home page). - The JSON API already provides a good deal of what some of the above would need, and it might become activated by default. Before this happens, a full audit of the code is necessary, as well as stress tests to check for memory mishandling and whatnot (a fuzzer test - i learned a new word today). - External repositories (a-la SVN or git modules) came up once or twice, but we didn't actually discuss adding it to fossil. i'd like to throw it out there as a potential TODO, though. In short, this allows one to embed external repos as subdirs of one's own repo, and is normally used to pull in 3rd-party code upon which an app depends. A local pull would also pull x-repos, but they would not participate in push (that might be the next step, of course). - Fossil timeline graph in CLI mode (like git). Several other git-like features came up but i do not recall what they were :/. (@self: remember to put DRH in touch with your libgit2 contact.) In the 11 hours we discussed a great deal, and there was certainly more that i missed altogether or didn't manage to jot down, and i would ask the other attendees to extend the above if i've left anything interesting out. @non-attendees: i intentionally left some of the above quite vague to try to spark your imaginations. Some of the topics we discussed in some detail, including potential implementation strategies, but rather than describe that i'd like to hear what ideas others can derive from the descriptions above. i unfortunately failed to take any pictures except one of the whiteboard. :/ We would love to hear your thoughts/elaborations on the above ideas. Happy Hacking! PS: Please pardon my brevity and typing mistakes - i'm on a tablet. ___ 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
Re: [fossil-users] Postmortum: DRH in Munich
On Wed, Jul 4, 2012 at 10:00 AM, Ramon Ribó ram...@compassis.com wrote: That it allowed to have more than one tickets list, with different tables and reports in every list. That's an interesting idea. i don't know if the current architecture would play well with that (maybe it can), but i've just written it down on my v2 list. i know the current code lets one add his own fields, and those fields could theoretically be used for grouping purposes. The permissions would span groups, but fossil's permissions system isn't granular enough for us to say user X has access to ticket group A, but not groups B and C. Maybe the permissions is something we could/should revisit for v2 (but so far the current system has been granular enough for what we've wanted to to). 2- Use fossil as a tool or library for other apps in order to access a dabatase with tables with full history and with easy syncronization. This is something that sqlite does not offer by itself Unfortunately, fossil's architecture does not allow it to be easily refactored as a library/application combination. The effort required to do so would be relatively large - several full-time person-weeks, at least, i suspect (and all of us have day jobs), and that's not accounting for some of the new issues that would bring with it (e.g. multi-threading and how it changes db error handling). During that time other development would need to stop and we would probably introduce all kinds of new bugs along the way. That said: when we get around to writing v2, i think there is no (or little) disagreement that a library is the proper thing to do (for many reasons discussed at length on the list late last year or early this year). For v1, by the time the librification momentum was there, the project was too big to just refactor as a weekend project. -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Postmortum: DRH in Munich
On Wed, Jul 4, 2012 at 10:34 AM, Joan Picanyol i Puig lists-fos...@biaix.org wrote: Sounds great, as long as it is not a requirement (either in fossil nor in the client). I guess the wiki markup issue is a done deal then? The wysiwyg would be an option, either at the repo or user level (maybe both, we're not yet sure). With the custom pages feature we could in fact provide multiple editors with relatively little work, and let the client simply choose his default editor page. - Adding more metadata to wikis, e.g. a title field. We might embed this into the wiki content using a new wiki tag or similar. This would be great if it enabled keyword based tagging for later search. What do you mean by keyword based tagging? (i'm not a search expert.) Full text search is difficult in fossil because things are stored as deltas. However, i believe someone (don't remember who) was working on this and i _thought_ there was a branch somewhere for this. We will have to enable the style attribute on tags in the wiki content (style is currently filtered out by the wiki out of safety concerns), and if anyone can name a concrete security reason why that would be a Bad Idea, please speak up! This sounds like a wide open door for XSS attacks. https://www.owasp.org/index.php/XSS_%28Cross_Site_Scripting%29_Prevention_Cheat_Sheet#RULE_.234_-_CSS_Escape_And_Strictly_Validate_Before_Inserting_Untrusted_Data_into_HTML_Style_Property_Values Is there a specific attack (or attacks) then you can imagine which might be a problem for us? (i'm no security expert, either!) During our meeting we came to the conclusion that allowing style attributes should be a benign change, but we're also aware that there are people out there who are more devious than us and how might come up with abuses. How about if we restricted style attributes to class attributes (as opposed to concrete style information)? e.g. this would be legal: span class=wiki-bold.../span but this would not (as it currently is not): span style=font-weight: bold.../span :-? - Adding a system for integrating custom pages to fossil repos, e.g. /myCustomPage, which would call content stored in the db. The original ... I smell AOLServer... i'm not familiar with it. keep up the good work :-D Thanks for the feedback! -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ 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] Stash with renames
On Wed, Jul 4, 2012 at 8:49 AM, Lluís Batlle i Rossell vi...@viric.namewrote: in a save operation. Can you reproduce it? On Wed, Jul 4, 2012 at 8:49 AM, Lluís Batlle i Rossell vi...@viric.name wrote: in a save operation. Can you reproduce it? Okay, to make sure i've got this right: f mv file1.old file1.new f stash save add/edit other files? f stash pop and the changes from the 3rd step are reverted? (f=symlink to fossil on my system) Here's what i've tried: stephan@tiny:~/cvs/fossil/test$ fst repository: /home/stephan/cvs/fossil/test/../test.fsl ... EDITED hosts RENAMEDresolv (resolv.conf was rename to resolv) stephan@tiny:~/cvs/fossil/test$ f stash save REVERTED: hosts REVERTED: issue REVERTED: resolv.conf Then i started over, did mv resolv.conf foo, made a separate edit, and got myself into this state: stephan@tiny:~/cvs/fossil/test$ fst ... EDITED foo EDITED hosts (foo was actually moved _and_ edited) stephan@tiny:~/cvs/fossil/test$ f stash save foo REVERTED: resolv.conf resolv.conf was foo before a mv operation, so that should arguably say reverted foo instead of reverted resolv.conf, but that's splitting hairs. stephan@tiny:~/cvs/fossil/test$ fst ... EDITED foo EDITED hosts that's actually what i would expect, but: a) i might have missed an obvious logic error. b) like i said, i suspect you had another step or two which i didn't. c) ACTUALLY... i wouldn't have expected stash/unstash of a rename to work, and am pleasantly surprised to see that it does ;). Can you send me the steps to reproduce? i've got another 2.5 hours or so of hacking time left tonight. :-? -- - stephan beal http://wanderinghorse.net/home/stephan/ http://gplus.to/sgbeal ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] How do I rebuild my fossil repo?
Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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 do I rebuild my fossil repo?
Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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] How do I rebuild my fossil repo?
On Thursday, July 5, 2012, Stephan Beal wrote:
Nothing can be removed from fossil. Ever. There is no way to shrink a
repo, only to re-create it with the desired files.
Ouch. How could then I transfer current tickets into the newly created repo?
On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim
imra...@gmail.comjavascript:_e({}, 'cvml', 'imra...@gmail.com');
wrote:
Hi,
My problem is that when I started using fossil, there are so many
unwanted files getting added my repository. Now, my repository database has
already grown to 700mb. Some files were data files which were accidentally
added by using addremove. My searching points to 'shun'; but it is
impossible, since I could not find artifact that could be shunned. And
painful, even if I found those files, since it could be numerous. What I
want to do is to get a clean repo with current files I have in my checkout
folders, with all tickets and historical events for those files.
Thank you for any help rendered.
best regards,
Radzi.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org javascript:_e({}, 'cvml',
'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] How do I rebuild my fossil repo?
With help of some scripting and SQL, you can find all UUIDs for files that you want to remove and shun them. after that when you rebuild, your repo file will be shrunk. It is a bit effort though. - Original Message - From: Stephan Beal Sent: 07/05/12 09:15 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How do I rebuild my fossil repo? Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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] The command update --nochange actually changes _FOSSIL_
Hi All, Just something I noticed that seems un-intuitive and makes calling the binary from something like PHP more difficult. The --nochange option is documented as do not perform changes but show what would be done so it really shouldn't change _FOSSIL_. If you don't have write permission to _FOSSIL_ you can get the following error: steve@VaioLx:~/sandbox/research/repo/work$ fossil update trunk --nochange fossil: SQLITE_READONLY: statement aborts at 39: [UPDATE vfile SET mtime=(SELECT mtime FROM vfile WHERE id=:idv) WHERE id=:idt] attempt to write a readonly database fossil: SQL error: attempt to write a readonly database I am not quite sure why it would update the timestamp for a dry run. Maybe that code can be bypassed with the --nochange option. -Steve ___ 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] The command update --nochange actually changes _FOSSIL_
On Thu, Jul 5, 2012 at 12:30 AM, Steve Waggoner stwaggo...@gmail.comwrote: Hi All, Just something I noticed that seems un-intuitive and makes calling the binary from something like PHP more difficult. The --nochange option is documented as do not perform changes but show what would be done so it really shouldn't change _FOSSIL_. If you don't have write permission to _FOSSIL_ you can get the following error: steve@VaioLx:~/sandbox/research/repo/work$ fossil update trunk --nochange fossil: SQLITE_READONLY: statement aborts at 39: [UPDATE vfile SET mtime=(SELECT mtime FROM vfile WHERE id=:idv) WHERE id=:idt] attempt to write a readonly database fossil: SQL error: attempt to write a readonly database I am not quite sure why it would update the timestamp for a dry run. Maybe that code can be bypassed with the --nochange option. --nochange means no changes to the repository. The _FOSSIL_ file is a different matter. Fossil has to update the timestamps in _FOSSIL_ in order to figure out what would need to be updated. -Steve ___ 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] How do I rebuild my fossil repo?
That question botheres me to. It would be really handy to be able to
export/import Tickets and Wiki Information.
Am 05.07.2012 05:57, schrieb Mohd Radzi Ibrahim:
On Thursday, July 5, 2012, Stephan Beal wrote:
Nothing can be removed from fossil. Ever. There is no way to
shrink a repo, only to re-create it with the desired files.
Ouch. How could then I transfer current tickets into the newly created
repo?
On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com
javascript:_e({}, 'cvml', 'imra...@gmail.com'); wrote:
Hi,
My problem is that when I started using fossil, there are so
many unwanted files getting added my repository. Now, my
repository database has already grown to 700mb. Some files
were data files which were accidentally added by using
addremove. My searching points to 'shun'; but it is
impossible, since I could not find artifact that could be
shunned. And painful, even if I found those files, since it
could be numerous. What I want to do is to get a clean repo
with current files I have in my checkout folders, with all
tickets and historical events for those files.
Thank you for any help rendered.
best regards,
Radzi.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org javascript:_e({}, 'cvml',
'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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
Re: [fossil-users] How do I rebuild my fossil repo?
On Thu, Jul 5, 2012 at 12:17 PM, altufa...@mail.com wrote: With help of some scripting and SQL, you can find all UUIDs for files that you want to remove and shun them. after that when you rebuild, your repo file will be shrunk. It is a bit effort though. Could somebody point out to the documentation of internal table structure and their relationship? - Original Message - From: Stephan Beal Sent: 07/05/12 09:15 AM To: Fossil SCM user's discussion Subject: Re: [fossil-users] How do I rebuild my fossil repo? Nothing can be removed from fossil. Ever. There is no way to shrink a repo, only to re-create it with the desired files. On Jul 5, 2012 2:54 AM, Mohd Radzi Ibrahim imra...@gmail.com wrote: Hi, My problem is that when I started using fossil, there are so many unwanted files getting added my repository. Now, my repository database has already grown to 700mb. Some files were data files which were accidentally added by using addremove. My searching points to 'shun'; but it is impossible, since I could not find artifact that could be shunned. And painful, even if I found those files, since it could be numerous. What I want to do is to get a clean repo with current files I have in my checkout folders, with all tickets and historical events for those files. Thank you for any help rendered. best regards, Radzi. ___ 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 mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
