[fossil-users] Fossil destroys repositories?

2011-07-26 Thread Russ Paielli
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?

2011-07-26 Thread Mike Meyer
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?

2011-07-26 Thread Eric

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

2011-07-26 Thread Lluís Batlle i Rossell
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

2011-07-26 Thread Jan Danielsson
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

2011-07-26 Thread Remigiusz Modrzejewski

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?

2011-07-26 Thread Remigiusz Modrzejewski

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

2011-07-26 Thread Remigiusz Modrzejewski

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?

2011-07-26 Thread Gé Weijers



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

2011-07-26 Thread Ron Wilson
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)

2011-07-26 Thread Stephan Beal
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?

2011-07-26 Thread Eric

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

2011-07-26 Thread Russ Paielli
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

2011-07-26 Thread Ron Wilson
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