[fossil-users] Fossil destroys repositories?
I posted a recommendation for Fossil earlier today on a Scala forum (see my earlier post today on this forum). I got this reply: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? --Russ P. -- http://RussP.us ___ 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 destroys repositories?
On Mon, 25 Jul 2011 23:20:31 -0700 Russ Paielli russ.paie...@gmail.com wrote: I posted a recommendation for Fossil earlier today on a Scala forum (see my earlier post today on this forum). I got this reply: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? Already discussed at length on the list (http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html). IIRC, there was a subtle bug that caused a fossil update to update to an empty branch - which then removed most of his files (bug fixed during this discussion). At this point, none of his work was lost. However, he then panicked (not unreasonable) and in trying to get things fixed managed to do things that did lose work. I don't think enough information was ever posted to decide if fossil actually lost work, or if he just managed to destroy it while trying to recover from the checkout of nothing. mike -- Mike Meyer m...@mired.org http://www.mired.org/ Independent Software developer/SCM consultant, email for more information. O ascii ribbon campaign - stop html mail - www.asciiribbon.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] Fossil destroys repositories?
On Tue, July 26, 2011 7:20 am, Russ Paielli wrote: I posted a recommendation for Fossil earlier today on a Scala forum (see my earlier post today on this forum). I got this reply: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? --Russ P. This was discussed here at the time, see the archives at http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html Eric -- ms fnd in a lbry ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] Links to events
Hello, long ago I opened this issue, about links to events not being resolved (thus appearing in read with no href). http://fossil-scm.org/index.html/tktview?name=b5efc3a47b I don't know if I should open a new issue... but the links still don't work at least for the timeline, checkins, or tiquets. The checkin related to the fix talks only about /info, but I'm not really sure of the implications fo this. But I think the links to events should work everywhere. Thank you, Lluís. ___ 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] Automatic branch color selection. Was: Question on short-lived branches in fossil
On 07/23/11 01:25, Richard Hipp wrote: [---] I tried Ross's proposed color choosing algorithm but it didn't work out. So instead I used the hash to select a Hue in an HSV color space, held the S and V fixed, and mapped the result into RGB. The color chooser code is here, if you are interested: http://www.fossil-scm.org/fossil/artifact/506fc3a6b2808?ln=116,144 Feedback is encouraged. Remember this changes is experimental and might disappear at any moment! I really like this feature. I haven't followed the thread, but whoever first came up with this feature is a genius. Each time I branch, I need to start looking up appropriate colors. It doesn't take long, but if one sums together each time .. too much time has been wasted in the end. These small time-savers are much appreciated. -- Kind regards, Jan Danielsson ___ 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] Automatic branch color selection. Was: Question on short-lived branches in fossil
On Jul 23, 2011, at 01:25 , Richard Hipp wrote: An experimental change to implement this is on the server. Add the brbg query parameter to the timeline method to have the background color set by branch name. Add ubg to have the background color set by user name. Examples: http://www.fossil-scm.org/fossil/timeline?n=200y=cibrbg http://www.fossil-scm.org/fossil/timeline?n=200y=ciubg Just what I asked for :) Kind regards, Remigiusz Modrzejewski ___ 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 destroys repositories?
On Jul 26, 2011, at 09:07 , Mike Meyer wrote: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? Already discussed at length on the list (http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html). IIRC, there was a subtle bug that caused a fossil update to update to an empty branch - which then removed most of his files (bug fixed during this discussion). At this point, none of his work was lost. However, he then panicked (not unreasonable) and in trying to get things fixed managed to do things that did lose work. I don't think enough information was ever posted to decide if fossil actually lost work, or if he just managed to destroy it while trying to recover from the checkout of nothing. IIRC he lost his changes by issuing fossil revert, what was the expected result. About general reliability: I've never encountered any data loss/corruption with Fossil. This is even when I use my own compiled versions derived from the trunk at random moments. It's also quite rare to read about any bugs in the software. I'd say it's built to a pretty good quality, but not yet the one of sqlite. Also the process is a bit lacking, with the ticket system being a ghost town (see http://fossil-scm.org/index.html/rptview?rn=2). But then again, it just works :) Kind regards, Remigiusz Modrzejewski ___ 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 for code review
On Jul 25, 2011, at 20:26 , Russ Paielli wrote: I am wondering how good Fossil is for code review on a large project. (I am a Fossil user, but I am currently only using it in the most basic way, for my own project with no collaboration.) Fossil has no specialized facilities for code review (there's even no way to comment a single checkin, other than commit message). Furthermore the default build still lacks hooks, which prohibits building any smart code review enforcement over it. If you don't need anything that advanced, it's quite OK. You can add/remove tags after committing. As a branch is a propagating tag, you can get something into/outside the working branch (see http://fossil-scm.org/index.html/timeline?r=Mistake for an example usage in a real repo). This way you can put a stamp on reviewed code/reject bad code/whatever your workflow wants. If you don't shudder on that kind of idea, you can event put review comments in commit message. Finally, knowing a tiny part of Fossil internals, I think that adding review facilities to the core would not be extremely hard. But someone would need to propose something good ;) Kind regards, Remigiusz Modrzejewski ___ 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 destroys repositories?
On Mon, 25 Jul 2011, Russ Paielli wrote: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html I expect that mr. Shaw will shoot himself in the foot using git rebase or git push --force one day and abandon git for something else... I use feature branches all the time, and I have never lost anything that can be blamed on Fossil. And I have backups, because I cannot expect to protect me against head crashes, OS bugs, and Monday mornings Gé___ 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 for code review
On Mon, Jul 25, 2011 at 2:26 PM, Russ Paielli russ.paie...@gmail.com wrote: I am wondering how good Fossil is for code review on a large project. (I am a Fossil user, but I am currently only using it in the most basic way, for my own project with no collaboration.) If your developers are making commits to their own branches, then your review process can selectively merge in the changes that are accepted. As Remigiusz mentioned, tags can be added to a commit to indicate Accept/Reject status from the reviewers. If the consesus is to accept the code, then your integrator can merge in the accepted changes. Since tags can have a value, they can reference a document with a detailed report from the reviewer. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
[fossil-users] JSON-based API (WAS: Fossil for code review)
On Tue, Jul 26, 2011 at 8:13 PM, Ron Wilson ronw.m...@gmail.com wrote: As Remigiusz mentioned, tags can be added to a commit to indicate Accept/Reject status from the reviewers. If the consesus is to accept the code, then your integrator can merge in the accepted changes. Since tags can have a value, they can reference a document with a detailed report from the reviewer. Just kind of a related pipe dream: if we would add a JSON-based API for fetching and setting tags we could write client-side code (JavaScript) which could handle much of the review process using existing infrastructure (the tags) as opposed to having to add code review support to the fossil core. That's arguably quite a bit out of scope for fossil, but i've always felt that it's CGI interface could be enhanced significantly via a JSON-based web-service-style API. i'd be up for working on that, if there's interest and we can come to a consensus on JSON call/response conventions. i've got a working JSON-based timeline in my fork, but a JSON-based web service would require significantly more intrusion than my very small patch. The infrastructure for parsing/reading/writing JSON is there, but the fossil internals might have to be touched in places in order to accommodate error reporting via JSON responses (as opposed to HTTP 500 when some operation fails and fossil exit()s). An example of what i mean: Fetch timeline: http://.../json/timeline?... Response payload (minus a response-type-agnostic envelope): [ { rid:11851, uuid:d640fdbd5014ac04d0711c963eadeb5a6754df3c, mDateTime:2011-04-20 16:51:23, comment:merged in trunk [085b6a1bbba91bbdd07]. (user: stephan tags: sgb-cson), primPlinkCount:0, plinkCount:2, mtime:2455672.202353 }, ...] (that was output by my local patch.) Login: http://.../json/login POST body: { user:..., password:...} (POST so that login info does not end up in web logs!) Response: {authToken:...session ID...} Add a tag: http://.../json/tag/list POST body: {checkIn:..., raw:false} Response: [tag1,tag2,...] Add a tag: http://.../json/tag/add POST body: { authToken:session ID, name:..., checkin:..., value:...} Response: standard envelope with error code 0 (no extra payload required) ... :-? -- - stephan beal http://wanderinghorse.net/home/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] Fossil destroys repositories?
On Tue, July 26, 2011 8:07 am, Mike Meyer wrote: On Mon, 25 Jul 2011 23:20:31 -0700 Russ Paielli russ.paie...@gmail.com wrote: I posted a recommendation for Fossil earlier today on a Scala forum (see my earlier post today on this forum). I got this reply: And [Fossil] is reported to destroy repositories if someone branches: http://sheddingbikes.com/posts/1306005291.html Any comments? Already discussed at length on the list (http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04665.html). IIRC, there was a subtle bug that caused a fossil update to update to an empty branch - which then removed most of his files (bug fixed during this discussion). At this point, none of his work was lost. However, he then panicked (not unreasonable) and in trying to get things fixed managed to do things that did lose work. I don't think enough information was ever posted to decide if fossil actually lost work, or if he just managed to destroy it while trying to recover from the checkout of nothing. mike Panicking _is_ unreasonable - understandable in the circumstances perhaps, but definitely unreasonable. Having just re-read the entire original thread, I think the key message is in http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg04699.html As I understand it, the repository was never destroyed at all, and uncommitted chages were destroyed by a fossil revert which does exactly that by design. Regards, Eric -- ms fnd in a lbry ___ 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 for code review
You might want to take a look at this: http://www.fogcreek.com/kiln/features/code-reviews.html It's just something I stumbled across surfing the web. I have no idea how good it is or whether it makes any sense at all to add something like this to Fossil. --Russ P. On Tue, Jul 26, 2011 at 11:13 AM, Ron Wilson ronw.m...@gmail.com wrote: On Mon, Jul 25, 2011 at 2:26 PM, Russ Paielli russ.paie...@gmail.com wrote: I am wondering how good Fossil is for code review on a large project. (I am a Fossil user, but I am currently only using it in the most basic way, for my own project with no collaboration.) If your developers are making commits to their own branches, then your review process can selectively merge in the changes that are accepted. As Remigiusz mentioned, tags can be added to a commit to indicate Accept/Reject status from the reviewers. If the consesus is to accept the code, then your integrator can merge in the accepted changes. Since tags can have a value, they can reference a document with a detailed report from the reviewer. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users -- http://RussP.us ___ 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 for code review
On Tue, Jul 26, 2011 at 5:34 PM, Russ Paielli russ.paie...@gmail.com wrote: http://www.fogcreek.com/kiln/features/code-reviews.html It's just something I stumbled across surfing the web. I have no idea how good it is or whether it makes any sense at all to add something like this to Fossil. Possibly something like this could be done in Javascript or Java, but might require enhancements to Fossil to allow the applet to manipulate tags and tickets as needed. Otherwise, this would be a companion application, or something like the Jurassic Fossil native Windows GUI for Fossil. ___ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users