Re: [fossil-users] Shameless self-promotion

2017-09-14 Thread Michael Barrow
Done!

*michael at barrow dot me*
+1.541.600.2027

"Do not anticipate trouble, or
worry about what may never happen.
Keep in the sunlight." -- B. Franklin

On Thu, Sep 14, 2017 at 8:55 AM, Richard Hipp  wrote:

> If you'd like to help promote Fossil to unwashed masses who are still
> using Git, perhaps like or retweet
> https://twitter.com/robmurrer/status/908080904781869056 :-)
>
> --
> 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] Fossil is Awesome

2011-10-26 Thread Michael Barrow
Ditto. Please resist the temptation to make Fossil into bloatware. The best
thing about the app, in my opinion, is the amount of features it has all
contained in a single binary that can be deployed practically anywhere.

On Wed, Oct 26, 2011 at 2:02 AM, Ron Aaron r...@ronware.org wrote:

 On 10/26/2011 10:59 AM, Konstantin Khomoutov wrote:
  I strongly disagree.
  First, please don't fix what's not broken.
 Agree 100%

  P.S.
  I'm one of those crazy folks who usually has NoScript turned on except
  for the intranet sites, so yes, I'm biased.
 

 Yes, so am I  ...
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] More thoughts on locks

2011-10-20 Thread Michael Barrow
I just wanted to point out that Fossil has a Wiki and ticketing system built
into it; these are two other methods that could be used to communicate with
other team members that you would be working on something that they should
not touch. I'm just sayin'


Friends don't let friends use locks in their DVCSes

On Thu, Oct 20, 2011 at 10:57 AM, Matt Welland estifo...@gmail.com wrote:

 2011/10/20 LluĂ­s Batlle i Rossell virik...@gmail.com

 Thinking as if we had to implement locks some day...

 I just thought that we could have locks working not on
 file-paths-in-branch, but
 on artifacts. That would expand well to multiple branches.

 Then, if anyone gets the lock, and commits a new version, it could get
 locked
 automatically too, expanding the list of artifacts needing lock.


 Actually I think you might be right on locking across branches though I'm
 not 100% sure. The described mechanism sounds like a really good approach.


 Those artifacts that 'require lock' for edition could be checked out
 read-only.

 The list of locked artifacts could expand similar to the shun list, that
 can be
 told to be updated on autosync. And the list of lock owners too. Keeping
 the
 default remote as the source of locks.



 And apart, not requiring a locks implementation, there could be a fossil
 default-off option to simply check out binary files readonly (fossil seems
 to
 know what file is binary and what not). That would put a step before
 binary-file
 editions, inviting to team communication.


 This is a good idea I think. It does depend on good behavior of the tools
 however. For example the schematic editor in use here will clearly indicate
 that the file was opened read-only and it will not allow edits but I've seen
 tools that allow you to start editing and then you can't save because the
 file is read-only. Of course bad tools is no reason to hesitate implementing
 a good idea.


 If anyone think locks could help in their use of fossil, that chould give
 an
 opinion on this. I work either in a small team or alone, so I'm not very
 representative on this.


 I'm 99.9% certain that if locking of some sort were available that I could
 expand the use of fossil to certain binary files in our team.

 Interestingly I ran into a scenario where I wish I had locks for my lone
 use of fossil. I have documentation in Lyx format and although Lyx files can
 sometimes be merged it isn't easy to resolve conflicts if you make lots of
 changes. I had forgotten that I made some substantial changes on a branch
 and edited my Lyx doc on the trunk. It took me over an hour to resolve the
 differences and get Lyx to read the merged doc.

 If locks were available I'd personally keep Lyx files, graphics (even svg)
 and other not-easy-to-merge files locked so that I don't unknowingly edit
 them in parallel on different computers or different branches.



 ___
 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




-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] Veracity (was: Fwd: suggestion on fossil)

2011-10-19 Thread Michael Barrow
No -- please no locks! Remember, you are still free to use out-of-band
mechanisms to contact the other developers to coordinate your activity:
email, telephone, tweet, smoke signals, carrier pigeons, etc.

On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote:

 On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski 
 l...@maxnet.org.pl wrote:


 I seem to be still in the 80's... So how do you cope with edit conflicts
 on binary files today?


 i wasn't aware that people use them for binary files. i don't ever keep
 binary files in SCM, so i've never had that use case.


 Could a new special tag be used to implement lock-like behaviour? By
 special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).

 --
 - 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




-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] Veracity (was: Fwd: suggestion on fossil)

2011-10-19 Thread Michael Barrow
I get it, but I don't get it. Locks don't make sense in a DVCS. If I'm on a
plane (without wifi, of course) and I want to edit a binary file, I'd be
hosed because I wouldn't be able to push the lock to the central server.

What if, like the Fossil main repo for example, there are two central
servers?

I do like your approach of a wrapper so that crazy lock stuff doesn't
destroy the pristine awesomeness of Fossil itself. :-)

On Wed, Oct 19, 2011 at 4:24 PM, Matt Welland estifo...@gmail.com wrote:

 I sent out a description of how I think light weight locks could be
 implemented on top of fossil in a past email. In fact I'm making some good
 progress on implementing what I want in a wrapper around fossil (implement
 locks in addition to some other things). I can look into making the wrapper
 available if anyone is interested.

 As has been mentioned Locks are really helpful when managing data that
 can't be automatically merged. However the need is not for draconian control
 but more of a semaphore to prevent accidentally changing a binary file at
 the same time someone else does.

 A more than adequate lock/semaphore methodology could be implemented on top
 of fossil roughly like the following...

 files have two flags; lockcontrolled and lockstate

 User locks file(s): fossil lock file1 file2 ...
 1. Write permissions are removed
 2. Lockcontrolled flag is set
 3. Lockstate is set.
 4. Sync

 On check out
1. Files locked by others have write perms removed

 On commit
1. Changed locked files cause an error, override with -force

 On update
1. Update write permissions per the flags.
2. A locally changed locked file causes a merge failure

 On unlock for edit
1. If file not already locked
2. Update flags, sync
3. Open permissions

 Or something like that. I think the closely coupled agressive sync model
 fostered by fossil makes this very doable.

 Matt
 -=-

 On Wed, Oct 19, 2011 at 7:52 AM, Stephan Beal sgb...@googlemail.comwrote:

 On Wed, Oct 19, 2011 at 4:44 PM, Stephan Beal sgb...@googlemail.comwrote:

 On Wed, Oct 19, 2011 at 4:17 PM, Remigiusz Modrzejewski 
 l...@maxnet.org.pl wrote:


 I seem to be still in the 80's... So how do you cope with edit conflicts
 on binary files today?


 i wasn't aware that people use them for binary files. i don't ever keep
 binary files in SCM, so i've never had that use case.


 Could a new special tag be used to implement lock-like behaviour? By
 special i mean a reserved name (or name pattern, e.g. locked-by-USERNAME).

 --
 - 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



 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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] overwrite file (a=always/y/N)?

2010-12-22 Thread Michael Barrow
Slight correction: HFS+ if you created the filesystem w/o the
case-sensitivity option. the fact that case-insensitivity is the default
puzzles me, being a Unix purist and all. :-)

On Wed, Dec 22, 2010 at 1:54 AM, chi ml-fos...@qiao.in-berlin.de wrote:



 Russ Paielli wrote:
  Sorry if I am being dense, folks, but I keep getting this question when
  I open fossil:
 
  overwrite file (a=always/y/N)?
 
  It goes through all of my files with the same question. I have no idea
  what this means, why it is being asked, or what the correct reply is.
  Overwrite it with what? Will someone please give me a clue? Thanks.

 I get this question, if I e.g. close a working copy and then re-open it
 again. Because 'fossil close' do not delete the files from the working
 copy, the 'fossil open' afterwards will recognize that -- during
 checkout -- the actual file being checked out does already exists (not
 deleted by 'fossil close'). So it will ask you if it is safe to
 overwrite it with the one currently checked out.

 Another situation where this could be happen is, if you have file names
 differ only by upcase/lowcase spelling and are checking out on a
 filesystem that regard e.g. 'FOO.c' and 'foo.c' as the same filename
 (e.g. NTFS or HFS+).

 Does one of this explanation is matching your environment?

 Best regards,
 chi.

 (...)
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Michael Barrow
michael at barrow dot me
+1 (408) 782-4249
___
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 to fix SSL cert query problem...

2010-09-22 Thread Michael Barrow
On a couple of my machines, I'm getting the I don't recognize this
certificate error where fossil asks if you would like to accept now, not
accept, or accept forever. We say a to accept forever, but it continues to
ask us each time. I looked in the .fossil database and see an entry there
that has a stored cert. No, I didn't suck out that cert and confirm that it
is the right one, but I did delete it and fossil repopulated the database.

We're running:
This is fossil version [73c24ae363] 2010-03-18 14:20:33 UTC

Is it time to stop being lazy and jump forward a few releases?

-- 
Michael Barrow
michael at barrow dot me
___
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] autobuild

2010-09-14 Thread Michael Barrow
All of this gives me a headache. Talk about drifting away from the elegance
of Fossil: distributed revision control with tickets and a wiki in a single
binary. Let's get back to the original program, folks! You have so many
other choices for bloatware

:-)

On Tue, Sep 14, 2010 at 1:19 PM, Wolfgang rat...@stumvolls.de wrote:

 Yusuf X ys1...@... writes:

 
  Hi, I have a need to build a repository once it's checked in. A handy
  feature would be to trigger a script (i.e., ant build_repo1.xml)
  once code is pushed to the server for a particular repository. It
  should not be a large change; if it's not in, shall I add it?
 

 Hi

 ANother problem, based on the distributed nature of fossil, is the possible
 existence of forks!

 Maybe it would be a better way, to have a daemon, polling the fossil repo
 and
 forcing your action, when an event occurs. Therefor you can easyly ask
 timline.rss. This could be done for example with wget from the shell.

 best regards,Wolfgang

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Michael Barrow
michael at barrow dot me
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users


[fossil-users] Bug with fossil flattening tree during a 'fossil mv'

2010-06-24 Thread Michael Barrow
I wanted to move a directory up in the tree. Notice how fossil flattened the 
html subdir (highlighted in bold). Is this a bug or feature?

Version: [73c24ae363] 2010-03-18 14:20:33 UTC

crazy-arms:Projects $ fossil mv fstc/35c/* 35c/
RENAME Projects/fstc/35c/35c.pl Projects/35c/35c.pl
RENAME Projects/fstc/35c/35c.sql Projects/35c/35c.sql
RENAME Projects/fstc/35c/cornerclient.pl Projects/35c/cornerclient.pl
RENAME Projects/fstc/35c/cornerserver.pl Projects/35c/cornerserver.pl
RENAME Projects/fstc/35c/cornerweb.html Projects/35c/cornerweb.html
RENAME Projects/fstc/35c/cornerweb.pl Projects/35c/cornerweb.pl
RENAME Projects/fstc/35c/html/cie.html Projects/35c/cie.html
RENAME Projects/fstc/35c/html/oc.html Projects/35c/oc.html
RENAME Projects/fstc/35c/html/of.html Projects/35c/of.html
RENAME Projects/fstc/35c/html/oi.html Projects/35c/oi.html
RENAME Projects/fstc/35c/html/on.html Projects/35c/on.html
RENAME Projects/fstc/35c/lastRun.sh Projects/35c/lastRun.sh


--
Michael Barrow
michael at barrow dot me




___
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] Using ticket system from command line

2010-05-15 Thread Michael Barrow
I don't understand why you have to write your docs in Fossil's formatting 
language. Isn't that equivalent to being constrained to a particular 
programming language by the scm system? 


--
Michael L. Barrow

On May 15, 2010, at 5:23, Gour g...@gour-nitai.com wrote:

 On Sat, 15 May 2010 07:11:35 -0400
 Richard == Richard Hipp wrote:
 
 Dear Richard,
 
 Richard HTML is not complete enough?  What do you want to do (or for
 Richard that matter what does any other wiki system do) that you can't
 Richard do (in a more standard way, I should add) with HTML?
 
 it is not point that HTML is not complete, but it is simply too
 cumbersome to write documentation in HTML.
 
 Probably, that's why we have wikis and so many different kind of
 markup languages.
 
 For the same reason (cumberness), I do not use e.g. DocBook, but
 prefer more readable formats like Markdown and/or RestructuredText.
 
 Richard The philosophy of Fossil Wiki is to provide simple and common
 Richard wiki-style markup to accomplish 90% of what you need, then
 Richard allow the use of HTML for the other 10%.  
 
 Fossil's wiki is simply too limiting. E.g. Only a single level of
 bullet list is supported by wiki. For nested lists, use HTML. is not
 acceptable for the writing docs, but I believe there is no need to
 repeat oneself since there are so many messages which were discussing
 the issues and several people expressed their sentiments in regard.
 
 RichardHTML is seen as superior to increasingly arcane Wiki
 Richard formatting for the complicated stuff because (1) most
 Richard programmers already know HTML so there is nothing new to
 Richard learn, 
 
 Why you restrict usage of (Fossil) SCM only to programmers?
 
 I use SCM for ALL my writings and majority of that is not the code.
 
 Richard (2) HTML is a standard, 
 
 Yes, afaict, people desiring to see 'standard' wiki were/are ready to
 accept ANY COMPLETE wiki since it means support for converting,
 editing-modes etc, i.e. one can do ALL the documentation in the one
 wiki markup.
 
 Richard (3) HTML allows you to do just about whatever you want to do
 Richard in a web browser - it is complete.  
 
 The point is that by using e.g. Markdown/reST (along with Pandoc) it
 enables me to target not only HTML, but many other formats like PDF
 (check http://johnmacfarlane.net/pandoc/)
 
 Richard You can disagree with the design choice here.  
 
 I do. :-)
 
 Richard But please distinguish between a lack of understanding and a
 Richard disagreement.
 
 I understand it is your choice since Fossil is your offspring.
 
 Richard The fossil ui command lets you do exactly that.  I use
 Richard Fossil daily for work on SQLite.  I normally enter and/or edit
 Richard tickets off-line (using the fossil ui command) then push
 Richard them up to the servers later.  
 
 btw, what do you think about:
 
 http://www.fossil-scm.org/index.html/tktview?name=3e3018e96f ?
 
 RichardThis is the standard way of working with Fossil.
 
 Ahh...
 
 Richard I am sorry that you were left with the impression that one
 Richard had to be online and connected to a server to work with
 Richard Fossil tickets.  I thought the documentation was reasonably
 Richard clear on the point that tickets and wiki could be edited
 Richard offline.  Perhaps I can find a way to make it clearer.
 
 I believe there is no need to clarify documents...The problem was that
 I was so absorbed in cli-interface (reading roundup docs) that I
 completely forgot about 'fossil ui'.
 
 Sincerely,
 Gour
 
 -- 
 
 Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
 
 ___
 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] Using ticket system from command line

2010-05-15 Thread Michael Barrow
You can create tickets now (not via cli, but via the local web interface) and 
sync them. What's wrong with the current capability?


--
Michael L. Barrow

On May 15, 2010, at 3:51, Gour g...@gour-nitai.com wrote:

 On Sat, 15 May 2010 11:30:40 +0100
 Eric == Eric wrote:
 
 Eric  Otherwise, lack of standard wiki
 Eric 
 Eric I continue to be amazed by all this nonsense about the wiki.
 
 s/standard/complete/g
 
 
 Eric   email interface for the tracker
 
 Eric I don't know if it has a name but there seems to be a law that
 Eric once a software product is sufficiently popular people want it to
 Eric do everything, i.e. they want it to be a platform.
 
 My mistake...
 
 s/email/cli/g
 
 I believe it's reasonable to expect that in distributed tracker once
 can create tickets via cli while being offline and push to the
 'central' repo when online.
 
 Excuse me for creating unnecessary disturbance...
 
 
 Sincerely,
 Gour
 
 -- 
 
 Gour  | Hlapicina, Croatia  | GPG key: F96FF5F6
 
 ___
 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] Direct URL for downloading a file from the repository via CGI interface

2010-03-18 Thread Michael Barrow
I'm trying to make a URL with a link to directly download something from the
repository. By navigating through the Files interface, I eventually see
the Download link and could definitely use this. However, I have a
question: what's the purpose of the name=XX at the end of the URL. For
example,
http://server/repo/raw/path1/path2/file.c?name=22

-- 
Michael Barrow
michael at barrow dot me
___
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] Deleting a wiki page?

2010-03-17 Thread Michael Barrow
There is no such thing as a non-active Wiki page per se. You could remove
links to said page if you want to keep it around and then edit the page to
say Hey -- we're just keeping this for archival purposes. Otherwise, 'shun'
is the tool to use. I've done in on some of my installations for pages that
I really wanted to go away.

On Wed, Mar 17, 2010 at 2:11 PM, Jeremy Cowgar jer...@cowgar.com wrote:

 On 3/17/2010 5:09 PM, D. Richard Hipp wrote:
  You could shun all the wiki artifacts associated with that page.
  There is no other way at present.  Because the design of Fossil is to
  save everything forever, it is not clear would could be down to
  delete a wiki page.
 

 There has to be a way as we can delete a file from the SCM. We can also
 rename a file. I guess I am not talking about removing it entirly as if
 it had never existed. I am simply talking about removing it so it's no
 longer active and no longer appears in the /wcontent list.

 Jeremy

 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Michael Barrow
michael at barrow dot me
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users