from:"B Harder"

(copy/paste sbeal response in diff't thread)
 i looked into that sometime in the past year. In theory, once you can pop the 
 top-most
 commit, you can pop any number (but always from the top). But the devil's in 
 the details -
 getting each and every cross-reference and delta removed/replaced properly is 
 remarkably
 difficult.

Are references backward, forward, or both ? What I mean is,
roughly, is fossil a doubly linked list, or singly, and if single,
what direction?

-bch


On 10/28/14, Richard Hipp d...@sqlite.org wrote:
 On Tue, Oct 28, 2014 at 1:31 PM, B Harder brad.har...@gmail.com wrote:

  I would like an option to pop and discard from a branch
 tip. Possible? If the repo has been sync'd, then that work would come
 back to you on next sync (that's understood), but if it hasn't been
 sync'd, it could be useful.


 To do an uncommit for a check-in that has not yet been synced, all you
 have to do is identify the particular artifacts that were added by that
 commit (the  RCVFROM table should be helpful there) and remove them from
 the BLOB table of the database (taking care to also fix up the DELTA table
 so that it does not depend on any BLOB that you removed).  Then rebuild.

 You could perhaps omit the rebuild step if you go to the extra work of
 removing the artifacts from the various other tables in the database.  Or
 maybe you want an uncommit to force a rebuild in order to make it a
 little more painful, and hence discourage its use.  I dunno.

 If somebody has a patch for the above, we can look at adding it...

 --
 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] Uncommit. Was: Fossil checksum

That's pretty much what I figured... I'll have to dig in and
understand cards (and maybe sit down again w/ you and just generally
chat) -- but I expect to see a linear relationship. My intuition tells
me one ought to be able to pop-and-delete back to origin -- of
*course* if a repo has been replicated, a re-sync will (ought to)
re-populate... which is fine and good.


I guess the details would be:

1) how complex is the structure/relation that needs to be popped to do
the operation as cleanly as possible

2) how much cheat room is allowed during the course of this
development whereby perhaps a single card/obj could be deleted, and
the dangling bits would be culled w/ a [f rebuild] ?

3) I can't think of anything else...


-bch


On 10/28/14, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Oct 28, 2014 at 7:05 PM, B Harder brad.har...@gmail.com wrote:

 Are references backward, forward, or both ? What I mean is,
 roughly, is fossil a doubly linked list, or singly, and if single,
 what direction?


 In this case it's like a stack and you could only delete from the top (and
 then the next top, ad nauseum...). You can't remove a link from the middle
 of the list without invalidating hashes.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf

___
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] Uncommit. Was: Fossil checksum

Not a bad idea -- this part of the description:
Furthermore, all shunned artifacts (but not the shunning list
itself) are removed from the repository whenever the repository is
reconstructed using the rebuild command.

may roughly be what we're looking for. We happen to be applying to a
specific artifact only (tip of branch) which shouldn't be any worse
than shunning in the middle of a branch, and may be simpler (barring
the fact that a tip will have to be properly identified as a tip).
Otherwise, there may be clues for what cards/blobs to target -- I also
presume that the rebuild (for the case of shun) is to re-rationalize
dependencies down the chain -- which won't be necessary w/ working on
a tip (?)

-bch


On 10/28/14, Ron W ronw.m...@gmail.com wrote:
 On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal sgb...@googlemail.com
 wrote:

 On Tue, Oct 28, 2014 at 7:14 PM, B Harder brad.har...@gmail.com wrote:

 3) I can't think of anything else...


 You will.


 Perhaps looking at how shunning works would help

___
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] Uncommit. Was: Fossil checksum

On 10/28/14, Richard Hipp d...@sqlite.org wrote:
 On Tue, Oct 28, 2014 at 5:17 PM, Ron W ronw.m...@gmail.com wrote:

 Maybe could be as simple as adding the relevant artifact IDs to the shun
 list and rebuilding. (Though that would be rather slow (which is not
 necessarily a bad thing for this feature)).


 Yep.  Just be VERY CAREFUL that you don't add an artifact that is also used
 in some other check-out that you want to keep, because after you shun it
 will be gone forever.

For that reason (and the extra baggage of the added element to the
shun list) I think that shun (proper) is not the ideal long-term
solution.

 --
 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] Anyway to diagnose a malformed disk image ?

2014-10-23 Thread B Harder

Done:

*** in database main ***
Page 36044: btreeInitPage() returns error code 11
Page 36045: btreeInitPage() returns error code 11
Page 36046: btreeInitPage() returns error code 11
Page 36047: btreeInitPage() returns error code 11
Page 36048: btreeInitPage() returns error code 11
Page 36049: btreeInitPage() returns error code 11
Page 36050: btreeInitPage() returns error code 11
Page 36051: btreeInitPage() returns error code 11
Page 36052: btreeInitPage() returns error code 11
Page 36053: btreeInitPage() returns error code 11
Page 36054: btreeInitPage() returns error code 11
Page 36055: btreeInitPage() returns error code 11
Page 36056: btreeInitPage() returns error code 11
Page 36057: btreeInitPage() returns error code 11
Page 36058: btreeInitPage() returns error code 11
Page 36059: btreeInitPage() returns error code 11
Page 36060: btreeInitPage() returns error code 11
Page 36061: btreeInitPage() returns error code 11
Page 36062: btreeInitPage() returns error code 11
Page 36063: btreeInitPage() returns error code 11
Page 36064: btreeInitPage() returns error code 11
Page 36065: btreeInitPage() returns error code 11
Page 36066: btreeInitPage() returns error code 11
Page 36067: btreeInitPage() returns error code 11
Page 36068: btreeInitPage() returns error code 11
Page 36069: btreeInitPage() returns error code 11
Page 36070: btreeInitPage() returns error code 11
Page 36071: btreeInitPage() returns error code 11
Page 36072: btreeInitPage() returns error code 11

[...]



On 10/23/14, Richard Hipp d...@sqlite.org wrote:
 On Thu, Oct 23, 2014 at 10:20 AM, B Harder brad.har...@gmail.com wrote:

 kamloops$ fossil open ../fossils/netbsd_src.fsl
 SQLITE_CORRUPT: database corruption at line 53640 of [e4ab094f8a]
 SQLITE_CORRUPT: database corruption at line 53679 of [e4ab094f8a]
 SQLITE_CORRUPT: statement aborts at 3: [SELECT 1 FROM event WHERE
 type='ci']
 fossil: SQL error: database disk image is malformed


 The first step is to run PRAGMA quick_check on the database file.
 --
 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] vendor branches, patches, and ancestors

2014-10-16 Thread B Harder

I'm maintaining a large(ish) repo for production deployments of
various software like Apache httpd, OpenSSL, etc.

What I have is a [vendor] branch for the vanilla vendor software (ie:
httpd-2.2.27.tar.gz), and feature branches for configuration/tweaks
(ie: [redhat_build] for building for redhat hosts).

Working with a model of this setup, it was interesting to me that if I:
b1 b2
|   /
|  /  --- divergent, no common artifacts.
|/
. [origin, trunk]


b1 branch == the [trunk] we're all familiar with
b2 == my [vendor]

Premise: I commit a file myfile to trunk (let's say contents are
I'm in trunk!), then checkout origin (an initial empty commit), and
then create a file myfile (contents: I'm in vendor!), and commit
--branch vendor.

If I f co trunk; f merge vendor, I'll get a no common ancestors
warning (which is expected), but *also* no change to myfile. I don't
know what the expect here per se, so I can't say it was unexpected.

If I then f co vendor; echo another line  myfile; fossil ci -m
'update on vendor'
then f co trunk;fossil merge vendor the effect (in [trunk],
remember) is a file:


I'm in trunk!
another line


I thought the effect was neat, and it's a bit different than how I
usually handle vendor branches (where I usually create a vendor branch
and immediately merge into trunk, then their inextricably linked from
the beginning of their lives as artifacts.

Interesting enough I thought I'd share.

-bch
___
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] Is it possible to add empty folders to the repo?

2014-10-06 Thread B Harder

Arguably, if you need empty dirs in your project as part of a build
process, it should be in the Makefile or equiv.

-bch

On 10/6/14, Gaurav M. Bhandarkar gaurav.a...@gmail.com wrote:
 maybe you could use :
 fossil settings empty-dirs

 A comma or newline-separated list of pathnames. On
 update and checkout commands, if no file or directory
 exists with that name, an empty directory will be
 created.


 On Mon, Oct 6, 2014 at 8:07 PM, Baruch Burstein bmburst...@gmail.com
 wrote:

 I tried doing:
 mkdir a
 fossil add a

 but that didn't work.

 --
 ˙uʍop-ǝpısdn sı ɹoʇıuoɯ ɹnoʎ 'sıɥʇ pɐǝɹ uɐɔ noʎ ɟı

 ___
 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] I have two trunks?

2014-10-02 Thread B Harder

Hi Dave.

This is a fork (unintentional branch). It would happen (for example)
if two different clones of a repository are updated independently of
each other, and then sync'd. You can merge the errant trunk back to
the good trunk without ill effect (minding you might have to do
conflict resolution). If you think of the case of two different clones
being updated as I described above, then ultimately merged together
(creating a fork in a branch), you'll see the DAG is maintained. The
labels for the branchname are maintained too, and the effect you see
(two Trunk branches) is consistent w/ the model. Re-merge them and
keep on developing !


-bch


On 10/2/14, dave d...@ziggurat29.com wrote:
 Hi list;

 Today I opened one of my repos, and expected to see some stuff that is in
 'trunk'.  However, it was empty as the day it was born.  I could see all my
 branches via 'branches', and could update to them, but when I would update
 to 'trunk' it would always be empty.  Odd, I thought, I'm quite sure I put
 stuff there, but 'oh, well', I thought, and I checked some stuff into it
 that I had expected to already be there, and then also made a branch for
 some other things, and checked them in, too.

 When I look at the timeline via fossil ui, I very clearly see I now have
 two
 trunks, the original one, and this new one.  I didn't even think this was
 possible, because I believed that fossil repos only have one unified DAG.
 Am I insane (er, 'am I in error', I mean to ask), or is this normal, and
 due
 to something odd that I did (though I can't imagine what it would be).

 This is not a secret repo; you can look here if curious:
 fossil clone http://chiselapp.com/user/ziggurat29/repository/z29-3rdParty
 3rdParty.fossil

 Thanks!

 -dave

___
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] I have two trunks?

2014-10-02 Thread B Harder

On Oct 2, 2014 11:14 AM, Andy Bradford amb-fos...@bradfords.org wrote:

 Thus said Stephan Beal on Thu, 02 Oct 2014 19:31:12 +0200:

  The weird  thing is, he's  got two initial  empty commits. i'm  at a
  loss to explain that.

 Seems that one of  them must have been created with  an older fossil and
 the  other  created with  a  newer  version  from Fossil's  trunk  which
 currently does  not force an  initial commit comment of  ``initial empty
 check-in'' when the fossil is created.

Is that even possible? I thought the repo would have to be created once
(and only once), generating it's repo-id, and then cloned for all
subsequent copies before things can begin deviating.

 Would be  interesting to know  how the  repository was created.  I don't
 know how Chiselapp imports a repository,  but is it possible that the it
 might have created the additional trunk when it was uploaded?

 Andy
 --
 TAI64 timestamp: 4000542d9630
 ___
 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] Files marked as missing after addremove

2014-09-12 Thread B Harder

I haven't had time to dig in, but that sounds like the ticket I opened this
week. If it sounds like that to you too, kindly add any more relevant info
you have:

http://fossil-scm.org/index.html/tktview?name=94a1f83f9f
On Sep 12, 2014 9:12 PM, Philip Bennefall phi...@blastbay.com wrote:

 Hi all,

 I am running a build of Fossil that is newer than the last public release,
 though I cannot remember exactly what check-in it is. I am having a bit of
 trouble with addremove. I remove the files in question from the repository
 and then I run addremove, and get the expected output which says deleted
 something.xyz. Then I run fossil commit, but it fails with a complaint
 about missing files. If I then say revert, and then use fossil rm to get
 rid of the files manually, status reports the files as deleted rather than
 missing. I don't recall having any issues with this in prior versions of
 Fossil. Am I doing something wrong in my workflow or is this potentially a
 bug?

 Kind regards,

 Philip Bennefall
 ___
 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] Tags in comment document

2014-09-06 Thread B Harder

On Sep 6, 2014 11:11 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Fri, Sep 5, 2014 at 10:07 PM, Philip Bennefall phi...@blastbay.com
wrote:

 whether it should really say branch rather than tags. Is this a bug, or
is it really meant to be branch rather than tags?


 It's probably just an oversight. IIRC, the --tag option to commit was
added relative recently (within the past year), and in my experience most
people provide the message on the command line, so they never see that. i
honestly can't remember the last time i let an scm start up an editor to
type in my commit message (several years, at the very least).

I do occasionally, and the rational came from an article I read on git
commits.  Roughly: put the briefest 80-col description on one line, next
para expands on that as necessary, and longer description follows (if
necessary). Our current default commit descriptions don't do anything
useful with this type of formatting, but it's easy to imagine spinning up
tooling that would. Facilities that used this (or similar) style of
formatting would encourage more people to adopt the style, which would not
be a bad thing.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 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] github gets split diffs

2014-09-03 Thread B Harder

https://news.ycombinator.com/item?id=8265249


Github gets split diffs, everybody rejoices.

-bch
___
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 vs git-based arrangements. code review and ticket export

2014-08-06 Thread B Harder

On 8/6/14, Ron W ronw.m...@gmail.com wrote:
 On Tue, Aug 5, 2014 at 5:16 PM, Warren Young war...@etr-usa.com wrote:

 On 7/26/2014 08:53, Eric Rubin-Smith wrote:


   * Code review!


 Your talk of state machines suggests that you're instead envisioning a
 system where you can't get a checkin into the trunk -- maybe not even
 into
 a development branch -- without someone else signing off on it.  If so,
 this is a terrible idea.


 It is possible, with no new features in Fossil, to prevent accidental
 commits to trunk. Since each developer will be working with a clone of the
 main repository, you simply do not give your developers commit permission
 to the main repository. When a developer has a change ready for review,
 she/he sends a review request with the name of the branch (on his repo).
 the the integrator (or an automated process) would then pull that branch so
 the reviewers can review if.

Do we have fine-grained control over pulling only specifically rooted branches ?


 Once approved, the integrator (possibly one
 of the reviewers) would merge the branch in to the trunk.

 FWIW, I think, behinds the scenes, you would find that VCSs that support
 approve-before-commit actually accept the (proposed) commit into an
 automatically created private branch, then move the commit to the target
 branch (or trunk) upon approval. While this could be implemented either in
 Fossil or in a wrapper for Fossil, the convenience it might provide
 really only manifests with very simple changes/fixes. But, when you need to
 iterate the process, you either end up with a new, single commit branch for
 each iteration, or you have to pull aside the curtain to find the
 branch's id and make further commits to that branch.

 Also, even if most of your changes/fixes are simple enough for a single
 commit each, having a real branch to work with makes it easier to manage
 integration because you can resolve most, if not all, of the integration
 issues in the branch before merging it into the target branch (or trunk).

___
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 now 7 years old

2014-07-26 Thread B Harder

Quotable:
I must say that Fossil is the best thing to happen
to my development workflow this year, as I am pretty sure that using
Git has resulted in the premature death of too many of my brain cells.
I'm glad to be able to replace Git in every place that I possibly can
with Fossil.
 On Jul 25, 2014 6:18 PM, Joe Prostko joe.pros...@gmail.com wrote:

 Congratulations!   I must say that Fossil is the best thing to happen
 to my development workflow this year, as I am pretty sure that using
 Git has resulted in the premature death of too many of my brain cells.
 I'm glad to be able to replace Git in every place that I possibly can
 with Fossil.

 The occasion of the seven year anniversary reminds me of something
 I've been meaning to ask on the list.  It has been asked in the past
 according to my check of the archives, but is there any chance you
 would be willing to go on Floss Weekly and talk about Fossil?  I know
 that you were on there to talk about SQLite quite some time ago, but I
 would love for there to be a show featuring Fossil.  I know that
 Randal's current way for projects to get on the show is that he will
 only schedule a time if the project leader(s) contacts him directly.
 In any case, I hope you will consider going on the show (alone or with
 another core committer), as it would be a great way to let more people
 know about the awesomeness that is Fossil.

 - joe

 On Fri, Jul 25, 2014 at 11:57 AM, Richard Hipp d...@sqlite.org wrote:
  The seventh anniversary of the first self-commit of Fossil source code
 was
  this past Monday.  Time flies.
 
  The logical predecessor of Fossil was CVSTrac (http://www.cvstrac.org/)
  which was a wiki and trouble-ticket system built atop CVS.  CVSTrac
 became
  the inspiration for Trac (http://trac.edgewall.org/wiki/CvsTrac) which
 is a
  similar tool for SVN that became far more popular than CVSTrac and which
 is
  still in active use.  Fossil was originally created to provide features
  needed in SQLite development, features that I couldn't get with
 CVS+CVSTrac,
  or with Monotone or Git or Mercurial or any other configuration
 management
  system available at the time.  I worked on prototypes of Fossil for a
 year
  or more prior to the first self-commit on 2007-07-21, but none of those
  early prototypes survive.
 
  Code archeologists will be able to find a lot of commonality between the
  CVSTrac and Fossil source codes.  There is a clear genetic relationship
  between the two systems.
 
  Fossil was created for the purpose of aiding in the development of
 SQLite.
  (Other uses for Fossil, though welcomed, are secondary.)  The SQLite
  documentation sources (
 http://www.sqlite.org/docsrc/timeline?a=2000-01-01)
  were split off from the SQLite source tree in CVS on 2007-11-12, just a
 few
  months after Fossil began self-hosting.  But the core SQLite source code
 did
  not move to Fossil until 2009-08-11, just after the release of SQLite
  version 3.6.17, over two years after Fossil became self-hosting.  The
 move
  from CVS to Fossil has proven to be a boon for SQLite development.
 
  CVSTrac was in active use by SQLite for a little over 7 years.  To my
  knowledge, nobody uses CVSTrac any more.  (OpenSSL was the last known
 user
  of CVSTrac and they switched over to Git at the beginning of 2013.)
 Fossil
  will soon overtake CVSTrac in terms of years of use, and Fossil has a
 great
  deal more momentum and a much larger user base than CVSTrac ever had.
 
  --
  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

___
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 vs git-based arrangements. code review and ticket export

2014-07-26 Thread B Harder

I'm on mobile device - please excuse typos/brevity.

I managed a team of about 10 local committers (in my office) and about 10
more remote (across the country).

I had a FreeBSD production environment. I setup a FreeBSD dev/testing
environment where everybody was isolated by jails, and had their own
personal full stack to work with. I encouraged (demanded) frequent commits
and good commit messages. Many, many commits per day from each developer as
they worked through their code. Each developer has their own named branch
(typically their username/personal name) that they owned and they were
responsible for. Developers were encouraged to talk amongst themselves and
merge each others code where they were working on systems that touched each
other. Devs used tags to mark their code as good when appropriate. To
maintain the stability of their own branches, they were encouraged to use
excursion branches where appropriate to isolate tricky work-in-progress.

I maintained trunk. I merged individual tagged dev branches at least once a
day, and worked out conflicts and stability with responsible devs when
necessary. On successful integration, passing tests, I would tag the trunk
commit and cut a release.

By *far* the biggest issue was where developers did not commit small enough
code changes, or merge other appropriate work frequently enough to keep
from diverging. Without fail, too long of a period between merging
appropriate code *into* their code, or tagging their code for merging into
trunk meant headaches.

Ironically, the single biggest disaster came from a collection of
developers who worked for the company financing the project. Despite daily
protests to tag their code for integration, for weeks they refused. Their
work was ultimately pretty much unintegratable, prompting the company to
send out one of their PMs across the country to fix our code. It was a
joke, but I digress.

Commit early. Commit often. Use branches and tags. Empower developers.
Recipe for success.
On Jul 26, 2014 7:53 AM, Eric Rubin-Smith eas@gmail.com wrote:

 I'm starting a company with some folks.  Their notion of the default
 choice for SCM is git + JIRA for bug tracking + some other tool we'd pick
 for code review.  This is probably quite common.  Since the answers to my
 questions will probably be interesting to a relatively wide audience, I
 hope the forum will forgive the length of my post.

 By 'code review' here I mean a web-based tool that has a formalized state
 machine for (a) uploading code deltas (b) filing and fixing defects against
 the uploaded code and (c) having the right set of people sign off.  Like
 Code Collaborator.  I guess JIRA has an integrated tool that is free for
 small teams too.  Whatever.  It just needs to eventually support reviewing
 every line of code that gets written, in case we decide to go in that
 direction.

 I'm trying to convince my co-founders to use fossil.  I won't address all
 of fossil's strengths, since you will all agree with me.  I want you to
 give me some ammunition on the weaker points:

  * Export of tickets.

 If we want to move away from fossil to a git-based thing in the future, we
 can export the source version history, though that is not as trivial as the
 Fossil page on the matter makes it seem (see below).

 Exporting the tickets is more of a PITA -- AFAIK I'd have to generate CSVs
 right from the SQLite database, massage them, and import them into JIRA (or
 whatever tool).  (In reality, it looks like JIRA supports JSON import, so
 I'd probably wind up writing code to read the SQLite database and emit JSON
 instead of CSV -- but whatever, similar idea.)  I'm guessing this would be
 like a 1-day project for a relatively large set of tickets.

 Furthermore, I'd need to massage all of the check-in comments themselves
 in order to reference the new JIRA IDs for tickets rather than the Fossil
 IDs.  Is there a better story than this?

  * Code review!

 DRH has said on this forum (and I'm paraphrasing here) that he prefers to
 review humans more than code.  If he decides he trusts the human, then he
 mostly trusts the human's output.  So he didn't really care to write a
 native tool for code review for Fossil.

 This is what I think I need the most help with.  While I feel mostly the
 same as DRH on the matter, I also would like to have a story in case one
 day the team decides they want to have every line go through a review
 process.  If I don't have a story up front for that then it will be a
 biasing factor against Fossil, since it will be more likely we'd need to go
 through a transition (one they would worry is onerous or error-prone) to
 some other SCM in the future.

 I've come up with some work-flows that sort of simulate code reviews right
 from within fossil.  For example, you might make each of your check-ins on
 its own branch, and when that check-in is accepted it gets merged into the
 feature branch.  The existence of a pending review is signaled by a naming

Re: [fossil-users] libfossil: new script binding

2014-07-17 Thread B Harder

On 7/17/14, Andy Goth andrew.m.g...@gmail.com wrote:
 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA1

 On 7/17/2014 3:22 PM, Stephan Beal wrote:
 in terms of memory use, it seems to be on par with lua, and lua is
 the lightest-memory interpreter i've yet run through valgrind. Most
 of them individually leak more memory than lua and s2 allocate
 combined.

 Sorry to drag this away from Fossil and TH1 and S2, but I suggest
 running Tcl in Valgrind sometime.  It's very, very good about memory
 usage.

+1

I'd be _very_ interested if some contrary conclusion was reached (as
would the Tcl core team).

 Aside from interim development versions, the only leak I've found is
 a performance optimization in which it doesn't bother free()ing
 everything on exit, much the same way Fossil doesn't clean up because
 it knows the operating system will do it faster and better.  There's a
 compile-time option set via preprocessor to make it go back to the old
 behavior of tidying up all allocations at the end.

 This is very important to me because I frequently use Tcl for testing
 other code written in C and Fortran and such, and I need Valgrind to
 spot my errors without being mired in the test harness.

 http://wiki.tcl.tk/3840

 - --
 Andy Goth | andrew.m.goth/at/gmail/dot/com
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v2.0.22 (MingW32)
 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

 iQEcBAEBAgAGBQJTyDQYAAoJELtYwrrr47Y4iBkH/j3cBBloLwFAxigrX8xhTydy
 I1c++agxS/veY0kdWoXqbnRYTluHXGlLy4JetWEOk3PmkgNa3EBZRsVtuUSRiqdl
 gpD1R0kP+7izLDlZuPKXWBjQNtdeAslSTcyuIFQVWTfHa1gFKT12GQ5oKuwo98yi
 Zl2uxhq6vgZK4cX3zg/S2SH2QA4avdMFJRxmBUXeBil6wqpr/oYKznD4kxtmTsEy
 zSysbC6Jz0l6dIbh+whAgNxhhf6QroItCwqCHtfeWBHkx05KCzUddXKizX72ggrz
 0aIu1loCz+Kb5v7JHnG8n8lzySTtKIBb0idUW5t1WCTmgJHyPrdLDvgmYrzOgBY=
 =XwRk
 -END PGP SIGNATURE-
 ___
 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 extras] versus symlinks

2014-07-10 Thread B Harder

It's clear people are split on what The Right Thing To Do is re: symliks.

I'm personally not sure; I don't use them in the course of development.
That said, I feel like they should *not* be in indirrected-through as a
matter of treatment. It's understandable those that _would_ like them to be
followed say: they're there, follow them., but what if a link points to
/etc? You want to publish your system config files? I feel that as a matter
of safety and *fossils* principles (as I understand them), the link should
not be interpreted. If you want to make a link that references something in
the working root of that repository's view (bounded at its root), then
putting it into a repo will not break anything. If you want to access
something outside the repo, i'm afraid I think this is bad repo
architecture. We already say no to introspection and special-handling for
(eg) line endings (Win versus Unix), and this principle of simplicity could
be applied to links as well. I feel there are greater inconveniences and
security risks with special treatment of links than without. Safety is at
risk, and though principle of least surprise seems to be touted by the
symlink followers, it can easily be applied to no special treatment for
symlinks as well.

Interested to witness the discussion though.
On Jul 10, 2014 7:29 PM, Timothy Beyer bey...@fastmail.net wrote:

 At Thu, 10 Jul 2014 09:52:13 -0700,
 Matt Welland wrote:
 
  [1  multipart/alternative (7bit)]
  [1.1  text/plain; UTF-8 (7bit)]
 
  [1.2  text/html; UTF-8 (quoted-printable)]
  What is allow-symlinks set to for you? From context it sounds like it is
 set to yes. If so this
  is *terrible* behavior and a bad bug. If it is set to 0 (IMHO an awful
 option that is default
  and should not even exist [i] ) then I think what you are seeing is the
 expected behavior.
 
  [i] In my opinion what you put in to a revision control system should
 *always* equal what you
  get out. The default fossil behavior of treating symlinks as extensions
 to the file tree
  fundamentally violates this principle. No need to debate this again. The
 fossil devs are
  adament that this is what they want but for the context of this
 discussion I wanted to mention
  my views on this point again.

 If the user doesn't want the contents of the symlink, then I would make
 one of
 the following suggestions:

 1) Set allow-symlinks to on, so that it will add the symlinks as files
 that
 are not followed, IIRC.  This is probably the behavior that the OP wants.
  I'll
 admit that this setting should be the default, although I find on to be
 fairly useless for my applications.

 2) Leave allow-symlinks on off, and put any offending symlinks files in
 the
 ignore glob, which is particularly useful in the presence of a versioned
 .fossil-settings/ignore-glob file.  I have done this for quite a while,
 and it
 has been quite effective and flexible.  I don't really understand why
 people
 have such strong objections to this method.

 3) If adding the file is a genuinely serious issue, consider if the
 symbolic
 link should even be in the path of the repository.  I'm not trying to play
 devil's advocate here, but I am curious as to the scenario that the user
 faces.
 I assume that they don't have control over what is present in the working
 directory? (In which case, either #1 or #2 apply).

 What I don't really understand is, why does a user want the symlink itself?
 This is likely far less valuable than the data stored inside of the
 symlink,
 and likely lacks relevance on other systems.  If the symlinks cannot be
 followed, then how is the user supposed to version data of a portion of the
 directory hierarchy below the current location? Further, if someone clones
 the
 repository on another unix machine, what happens if the path that it
 points to
 either doesn't exist, or points to something completely different?

 Second, versioning the symlink itself, rather than following it seems less
 portable to me.  OSes other than UNIX may not necessarily have symbolic
 links,
 so when a user clones that repository from Windows, I'm not sure how the
 symbolic links would be represented.  When they are followed, it just
 clones
 the raw files, so I see no portability issues in regard to solution #2.

 Someone brought up a ClearCase scenario, where the presence of versioned
 .fossil-settings/ignore-glob is an issue.  In this case, I would presume
 that
 ClearCase doesn't have a way to exclude fossil centric files?  In that
 case,
 suggestion #1 applies.  But if that is an issue, then why aren't .fslckout
 and
 the repository itself issues as well?

 Tim
 ___
 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] artifacts received

2014-07-07 Thread B Harder

That looks to be the end of this mystery. For those wondering why do
we request the same shun artifacts over and over and over and...:

==
The fact that the shunning list does not propagate is a security
feature. If the shunning list propagated then a malicious user (or a
bug in the fossil code) might introduce a shun record that would
propagate through all repositories in a network and permanently
destroy vital information. By refusing to propagate the shunning list,
Fossil insures that no remote user will ever be able to remove
information from your personal repositories without your permission.
==

Thanks Andy, Ron, Stephan, Donny.

-bch


On 7/7/14, Donny Ward donnyjw...@gmail.com wrote:
 Richard Hipp wrote about this before:

 https://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg11761.html

 His reponse in that link:

 The pull and sync are requesting and receiving all SHUN records. You can

disable this using

 fossil setting auto-shun off




 On Sun, Jul 6, 2014 at 3:10 PM, Andy Bradford amb-fos...@bradfords.org
 wrote:

 Thus said B Harder on Sun, 06 Jul 2014 14:40:58 -0700:

  myhost$ fossil pull http://joeb...@fossil-scm.org --http-trace
  Round-trips: 1   Artifacts sent: 0  received: 0
  Pull finished with 424 bytes sent, 612 bytes received

 It seems that I gave you the wrong option. Please try:

 fossil pull --httptrace

 Andy
 --
 TAI64 timestamp: 400053b9c98a


 ___
 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] artifacts received

2014-07-07 Thread B Harder

Good catch: you're correct.

-bch

On 7/7/14, Stephan Beal sgb...@googlemail.com wrote:
 On Mon, Jul 7, 2014 at 10:10 PM, B Harder brad.har...@gmail.com wrote:

 Fossil insures that no remote user will ever be able to remove


 Shouldn't that be ensures? i always confuse the two.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf

___
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] artifacts received

2014-07-06 Thread B Harder

myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 439 bytes sent, 2645 bytes received
myhost$ fossil pull http://joeb...@fossil-scm.org --http-trace
Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 425 bytes sent, 612 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 441 bytes sent, 2645 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 440 bytes sent, 2645 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 442 bytes sent, 2645 bytes received
myhost$ fossil pull http://joeb...@fossil-scm.org --http-trace
Round-trips: 1   Artifacts sent: 0  received: 0
Pull finished with 424 bytes sent, 612 bytes received



On 7/6/14, Ron Wilson ronw.m...@gmail.com wrote:
 On Sun, Jul 6, 2014 at 3:54 AM, Stephan Beal sgb...@googlemail.com wrote:


 Can't answer, but i see it only with 'pull', not with 'update'.

 [odroid@host:~/fossil/fossil]$ f pull
 Pull from http://step...@fossil-scm.org/index.html
 Round-trips: 1   Artifacts sent: 0  received: 74
 Pull finished with 453 bytes sent, 2644 bytes received

 [odroid@host:~/fossil/fossil]$ f up
 Autosync:  http://step...@fossil-scm.org/index.html
 Round-trips: 1   Artifacts sent: 0  received: 0
 Pull finished with 438 bytes sent, 612 bytes received


 Maybe there was nothing left for update to pull?

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

[fossil-users] artifacts received

2014-07-05 Thread B Harder

What are the artifacts received below? Is these administrative, or
is there something else at play?

myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 442 bytes sent, 2308 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 439 bytes sent, 2307 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 441 bytes sent, 2308 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 442 bytes sent, 2308 bytes received
myhost$ fossil pull
Pull from http://joeb...@fossil-scm.org
Round-trips: 1   Artifacts sent: 0  received: 74
Pull finished with 440 bytes sent, 2308 bytes received
myhost$
___
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] Sixteen-digit event IDs

2014-07-02 Thread B Harder

On Jun 30, 2014 2:20 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014-06-27 23:40 GMT+02:00 Andy Goth andrew.m.g...@gmail.com:
  How come events are always shown with (at least) sixteen digits on the
  timeline whereas other artifacts are given ten digits?
 
  http://www.fossil-scm.org/fossil/timeline?n=20y=e

 Just because it was implemented that way originally ;-)

 I would like to propose to use the same algorithm as in
 other places: Make sure that the displayed UUID contains
 at least one lowercase ASCII, with a minimum of length 10.

This code isn't an area of expertise of mine, but isn't the one lower case
ASCII requirement hopeful?

 The hyperlink uses the full UUID.
 The %S formatter could be used for the display part:
 http://fossil-scm.org/index.html/info/734d429940

 To me the result looks good, but I would appreciate a
 second opinion before merging this to trunk.
 Any objections? Is there any place in the UI where
 changing the default length of %S causes a
 possible incompatibility. (If so, using the
 %.16s format would be more logical anyway.)

 Regards,
 Jan Nijtmans
 ___
 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] no common ancestor

2014-06-18 Thread B Harder

If everything is (ultimately) spawned from the initial empty
checkin, how can I be getting WARNING - no common ancestor: path
when merging one branch into another ?

-bch
___
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 CLI tricks: interrupting a commit message

2014-06-17 Thread B Harder

On 6/17/14, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Jun 17, 2014 at 6:49 AM, B Harder brad.har...@gmail.com wrote:

 Remember that the buffer is only one level deep, though. A subsequent ^W,
 ^K , etc will clobber the previous contents.


 Almost: try 2x (NON-consecutively) ctrl-k (or ctrl-w, or whatever), then 1x
 ctrl-y, then Esc-y. Esc-y acts upon the previous Ctrl-Y, and subsequent
 Esc-y's pull back one proceeding entry further from the yank buffer.

Nice! As a BSD user though, I feel compelled to point out this looks
like a readline[1] feature, and not an editline[2] feature. So it
works with bash (and likely other readline linked progs), it doesn't
work w/ (e.g.) NetBSDs /bin/sh.


Good tip though.


[1] http://en.wikipedia.org/wiki/GNU_Readline
[2] http://thrysoee.dk/editline/

 Nonetheless, it is easy to lose text this way, so i recommend the comment
 method over the yank buffer.

 ($ is shell prompt).

 : is a command that consumes it's arguments and returns true.


 Another nice one. At times i've seen in-script docs done that way:

 : EOF
 docs go here...
 EOF

 Not sure why one would do it that way, though.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf

___
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 CLI tricks: interrupting a commit message

2014-06-17 Thread B Harder

On Jun 17, 2014 10:47 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jun 17, 2014 at 7:24 PM, B Harder brad.har...@gmail.com wrote:

 Nice! As a BSD user though, I feel compelled to point out this looks
 like a readline[1] feature, and not an editline[2] feature. So it
 works with bash (and likely other readline linked progs), it doesn't
 work w/ (e.g.) NetBSDs /bin/sh.


 i've always assumed it came from emacs (where i learned it), but it's
very possibly a readline feature emacs adopted. Then again, what _hasn't_
emacs adopted somewhere in some add-on?

Well, it's readlines (editlines) emacs editor emulation. You can also set
it up to be vi-like:

In ~/.inputrc:

set editing-mode vi

---

...so, you're not incorrect to think of it as an emacs feature (it is), but
this is readlines emacs-inspired implementation.

 Caveat: when you Esc-y you lose the top-most item in the yank buffer (the
one Ctrl-y yanked). i don't know of any way to restore them once you Esc-y
past them.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 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 CLI tricks: interrupting a commit message

2014-06-16 Thread B Harder

Remember that the buffer is only one level deep, though. A subsequent ^W,
^K , etc will clobber the previous contents.

Along lines of Stephan Beals method, I use : preceding the fossil
command. So:

$ : fossil ci -m 'some msg'

($ is shell prompt).

: is a command that consumes it's arguments and returns true.
On Jun 16, 2014 3:34 PM, Matt Welland estifo...@gmail.com wrote:

 Under bash another way to achieve the goal of temporarily putting your
 partially written commit command aside is to do: ^a ^k
 This puts your command in the cut buffer. To retrieve it (after having run
 fossil gdiff to figure out what you did!) just do: ^y




 On Mon, Jun 16, 2014 at 1:24 PM, Stephan Beal sgb...@googlemail.com
 wrote:

 Hi, all,

 This is for Unix-shell users only (including workalikes on Windows)...

 Here's a time-saving tip which i use very often myself, but most CLI
 users i know don't seem to know about:

 It often happens that i'm typing a commit message when i decide i need to
 stop and go check if what i'm typing in really reflects reality (or needs
 to be tested). So:

 fossil commit -m .INTERRUPT POINT

 You can stick that line in your command history without executing it by
 doing the following:

 1) Move your cursor to the beginning of the line. In Bash-like shells
 that's normally Ctrl-A, but many terminals support the Home key as well.

 2) Type the '#' character (shift-3 on a US keyboard). That's the shell's
 comment-to-end-of-line marker.

 3) Tap ENTER

 Or, in the Bash shell, simply:

 1) Tap Escape, then type the # character. That does all 3 of the above at
 once.


 Happy Fossiling!

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

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




 --
 Matt
 -=-
 90% of the nations wealth is held by 2% of the people. Bummer to be in the
 majority...

 ___
 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] Find in Files

2014-06-15 Thread B Harder

Cscope (+1) knows much more than just C.
On Jun 15, 2014 2:17 PM, Sergei Gavrikov sergei.gavri...@gmail.com
wrote:

 On Sun, 15 Jun 2014, Sean Woods wrote:

  Dear List,
 
  I am hacking on a large, complicated code base in my spare time for
  fun.  I unzipped the tarball with many source files and imported it
  into a Fossil repository.  This aids me greatly in reviewing the code.
 
  I often use the find . | xargs grep idiom (or some variant) to
  search within all the code files.  I am wondering how I could do this
  in Fossil?
 
  At minimum an SQL query would suffice but it would be super cool if I
  could do this through the web interface.
 
  Any ideas are much appreciated!

 If your code base is C sources and you can use TUI/GUI, cscope is the
 best choice for searching through sources http://cscope.sourceforge.net/

 Need Web interface? Try LXR http://lxr.sourceforge.net/en/index.shtml

 LXR self cross-referenced (under SQLite)
 http://lxr.sourceforge.net/demo/ident/lxr

 Sergei
 ___
 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] Cannot determine user when using -A

2014-06-08 Thread B Harder

Fossil certainly will spawn external programs if you:

1) start a commit w/o a command-line commit message

2) run a did with an external diff-command configured.

, maybe others.
On Jun 7, 2014 12:00 PM, Ron Wilson ronw.m...@gmail.com wrote:

 On Sat, Jun 7, 2014 at 11:52 AM, Stephan Beal sgb...@googlemail.com
 wrote:


 On Sat, Jun 7, 2014 at 5:18 PM, Will Parsons varro@nodomain.invalid
 wrote:

 Or you should be able to simply set the environment variable:

 $ USER=philip_bennefall

 and then you don't need to worry about the -A or --user options.


 That would work, but note that many programs use $USER to create strings
 (paths) and such, so reassigning it is generally not a good idea. However...

 export FOSSIL_USER=philip_bennefall

 should do the trick without endangering any other apps.


 Also:

 env USER= philip_bennefall fossil command options etc

 Will run fossil will that value of USER but not affect other things
 (unless fossil invokes them, but fossil doesn't do that)


 ___
 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)

2014-06-07 Thread B Harder

Hey Nico --

Some thought-provoking comments. Thanks.

-bch

On 6/7/14, Gour g...@atmarama.net wrote:
 Nico Williams n...@cryptonector.com writes:

 I wouldn't, don't, and won't  demand that anyone follow such a workflow
 for
 any codebase I don't own, and possibly not for codebases I own either
 (depends).  I only want to be able to do it myself easily when working
 on codebases where i have to or want to.

 You put it very nicely together!!

 I also want the power of SQL for history, and so on.

 +1


 Sincerely,
 Gour

 --
 Many, many births both you and I have passed. I can remember
 all of them, but you cannot, O subduer of the enemy!

 ___
 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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)

2014-06-05 Thread B Harder

drh Fossil allows you to commit a subset of files (by listing the
files on the fossil commit command line) but there is no mechanism
for committing a subset of lines within a single file.

That, and there _are_ branches/tags which are encouraged to be used...
my prev comment was for the case where a single file gets two-thoughts
worth of changes (subset of lines). For subsets of lines (assume we
want two logical commits), I head to my editor, tease out logical
section1 - tmp file. fossil stash save -m logical thought temp1
./file-of-interest;
re-enter tmp.file - file-of-interest; fossil ci -m description of
logical thought ./file-of-interest; fossil stash pop [edit if
necessary]; fossil ci -m description of other logical thought
./file-of-interest

If one is using feature branches though, you'll be prompted to save as
you switch between them, keeping your fossil repo up-to-date.

-bch


On 6/5/14, Richard Hipp d...@sqlite.org wrote:
 On Wed, Jun 4, 2014 at 11:08 PM, Alysson Gonçalves de Azevedo 
 agalys...@gmail.com wrote:

 I started to use fossil just today, but let me participate too :)

 Everyday I have a list of tasks that I have to work on and when I finish,
 I like to separate the changes of each task by commit.

 To do that, I just open GUI, check the lines of the files that i want to
 commit.
 (Just like this print:
 http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I
 click on the - and + to stage the line).

 But today, using fossil, I couldn't find anyway to do that, so I had to
 put all the changes on the same commit.


 Fossil allows you to commit a subset of files (by listing the files on the
 fossil commit command line) but there is no mechanism for committing a
 subset of lines within a single file.





 Well, in the theory I can work on one task at time and commit when I
 finish, but in the practice I work on all the tasks at same time.



 Alysson Gonçalves de Azevedo

 Anarcho-syndicalism is a way of preserving freedom. - Monty Python


 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com:

 On 6/4/2014 10:50, Richard Hipp wrote:


 The staging area complicates the interface.


 Perhaps you will add some of this to the Fossil vs Git wiki page.
 (Section 3.4?)

 ___
 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




 --
 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] Outside contribution feature

2014-06-05 Thread B Harder

On Jun 5, 2014 10:55 AM, Richard Hipp d...@sqlite.org wrote:




 On Thu, Jun 5, 2014 at 1:37 PM, Andy Bradford amb-fos...@bradfords.org
wrote:

 Thus said Warren Young on Thu, 05 Jun 2014 09:25:39 -0600:

  A  contribution  from  an  untrusted  outsider  needs  to  be  checked
  carefully before it is committed to the master repo.

 Certainly.

 fossil open subrepo.fossil
 # inspect
 fossil ui subrepo.fossil
 # inspect

 I'm not sure how many artifacts  would actually be required to make this
 work, but it does seem possib  le. Maybe it's too simplistic an approach
 and  it  would  actually  require  attaching  another  DB  as  has  been
 suggested.


 If you included all the artifacts that you need, that would immediately
make the subrepo larger than you might expect.  Certainly the subrepo would
be smaller if you only included artifacts that actually changed, and even
then only included deltas and not the complete text.

 But maybe there should be an open to the fossil submit or fossil
subrepo command (whatever it ends up being called)

A fossil partial?

 so that you can specify either a dependent or an independent
subrepository.  Dependent would be the default.  But you could request an
independent subrepo if you wanted to and space wasn't an issue.


 --
 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

Indeed, non-propagating tags are also checkout-able items.

What am I missing about bookmarks that we can't already enjoy w/ tags,
outside of new syntax ?

-bch


On 6/4/14, Richard Hipp d...@sqlite.org wrote:
 On Wed, Jun 4, 2014 at 12:03 PM, Nico Williams n...@cryptonector.com
 wrote:

 On Wed, Jun 4, 2014 at 9:07 AM, Stephan Beal sgb...@googlemail.com
 wrote:
  On Wed, Jun 4, 2014 at 12:02 AM, Nico Williams n...@cryptonector.com
  wrote:
  Mercurial too had heavy-duty branches only, then they added
  bookmarks that are very similar to git branches.  Since a bookmark
  is just a symbolic name for a commit... this is just a new table at
  best, with two columns.
 
  Bookmarks. That's a nice idea, actually. Added to my TODO list.

 It's interesting that I just sold you on the git branching model, by
 using the Mercurial analog.


 The Fossil and Git branching model are already the same, with the one
 exception that branch names in Fossil are global (they sync to other
 repositories) whereas in Git they are local to a single repository.

 Fossil also has something analogous to bookmarks - namely propagating
 tags.  You set a tag on a particular check-in, and that tag is
 automatically added to all direct descendents.  When you can check-out that
 tag and Fossil selects the most recent, which is the same thing as a
 bookmark that automatically moves to the head of the branch.


 --
 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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

Because the internet can be a poor medium to express emotional intent,
let me preface this with: Stephan, you know I have the utmost respect
for your coding chops, and we _mostly_ fall in line wrt design
philosophy. That said:

I'm shaking my head, wondering why? My current mental image is:
http://perl-begin.org/humour/perl6_perl_6_cover_lg.jpg

Is there an important, long-lived reason why we'd want this baked into
fossil? Maybe this deserves to live as a tool that happens to be
intimately familiar w/ fossil. Ie: a script that maps bookmarks with
the real UUID, and runs 'exec (fossil co $UUID);'.

-bch


On 6/4/14, Stephan Beal sgb...@googlemail.com wrote:
 On Wed, Jun 4, 2014 at 6:53 PM, B Harder brad.har...@gmail.com wrote:

 Indeed, non-propagating tags are also checkout-able items.

 What am I missing about bookmarks that we can't already enjoy w/ tags,
 outside of new syntax ?


 i envision them as being lightweight, i.e. local, non-versioned. They'd
 just be local aliases, in effect, to arbitrary other symbolic names.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf

___
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] Bookmarks (Re: git-fossil-git does not obtain the same commit hashes.)

sb fossil bk add xp experimental:2011-06-04

I can imagine this being useful at least occasionally. I'm still
loathe to include it in core fossil, but it'd be a great task for a
little tool.

-bch


On 6/4/14, B Harder brad.har...@gmail.com wrote:
 Because the internet can be a poor medium to express emotional intent,
 let me preface this with: Stephan, you know I have the utmost respect
 for your coding chops, and we _mostly_ fall in line wrt design
 philosophy. That said:

 I'm shaking my head, wondering why? My current mental image is:
 http://perl-begin.org/humour/perl6_perl_6_cover_lg.jpg

 Is there an important, long-lived reason why we'd want this baked into
 fossil? Maybe this deserves to live as a tool that happens to be
 intimately familiar w/ fossil. Ie: a script that maps bookmarks with
 the real UUID, and runs 'exec (fossil co $UUID);'.

 -bch


 On 6/4/14, Stephan Beal sgb...@googlemail.com wrote:
 On Wed, Jun 4, 2014 at 6:53 PM, B Harder brad.har...@gmail.com wrote:

 Indeed, non-propagating tags are also checkout-able items.

 What am I missing about bookmarks that we can't already enjoy w/ tags,
 outside of new syntax ?


 i envision them as being lightweight, i.e. local, non-versioned. They'd
 just be local aliases, in effect, to arbitrary other symbolic names.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf


___
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] Index (was Re: git-fossil-git does not obtain the same commit hashes.)

I've heard git allows this, and occasionally wished for it.

As it stands currently, it's not possible with fossil. There is a degree of
freedom in this regard using the fossil stash, though, which can be used
with some file jigging to separate two (or more?) logical ideas that one
wants committed discretely. Otherwise, fossils workflow really does
encourage the (highly regarded) tenet commit early, commit often.
On Jun 4, 2014 8:09 PM, Alysson Gonçalves de Azevedo agalys...@gmail.com
wrote:

 I started to use fossil just today, but let me participate too :)

 Everyday I have a list of tasks that I have to work on and when I finish,
 I like to separate the changes of each task by commit.

 To do that, I just open GUI, check the lines of the files that i want to
 commit.
 (Just like this print:
 http://i1-linux.softpedia-static.com/screenshots/gitg_5.jpg, where I
 click on the - and + to stage the line).

 But today, using fossil, I couldn't find anyway to do that, so I had to
 put all the changes on the same commit.

 Well, in the theory I can work on one task at time and commit when I
 finish, but in the practice I work on all the tasks at same time.



 Alysson Gonçalves de Azevedo

 Anarcho-syndicalism is a way of preserving freedom. - Monty Python


 2014-06-04 21:14 GMT-03:00 Warren Young war...@etr-usa.com:

 On 6/4/2014 10:50, Richard Hipp wrote:


 The staging area complicates the interface.


 Perhaps you will add some of this to the Fossil vs Git wiki page.
 (Section 3.4?)

 ___
 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

Re: [fossil-users] git-fossil-git does not obtain the same commit hashes.

2014-06-03 Thread B Harder

 Maybe convince the git developers to move their metadata into sqlite instead?

Ha! Thanks for putting a smile on my face Stephan.

-bch

On 6/3/14, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Jun 3, 2014 at 7:09 PM, Stephan Beal sgb...@googlemail.com wrote:

 precision differences in 4 records (0.24%) when converting those
 timestamps round-trip (from Julian to RFC8601, then back to Julian).


 ISO8601, of course. Maybe this clarifies what i meant there (output from a
 libfossil test app):

 iso8601 == julian tests...
 Running all event.mtimes through the julian==iso converters...
 1645 Julian timestamps tested from event.mtime.
 4 record(s) (0.24%) differed round-trip by 1ms (this is normal/not
 unexpected).


 If that 4 gets too high (i think i've got it set for 1%) then the test
 fails. The failure rates sway across different platforms, too.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf

___
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] DRH's PGCon 2014 Keynote (with Fossil sighting!)

2014-06-01 Thread B Harder

I think drh unnecessarily missed an opportunity there. He seemed to work
harder to obfuscate what fossil actually was than giving a single passing
description and moving on with his talk about SQL and using fossil by name
where it's used as an example.

Otherwise, interesting talk!
On Jun 1, 2014 8:10 PM, Scott Robison sc...@casaderobison.com wrote:

 On Sun, Jun 1, 2014 at 5:20 PM, Joel Bruick j...@joelface.com wrote:

 I just wanted to share Richard's PGCon 2014 keynote for anyone here that
 wasn't aware of it:


 Thanks for sharing that. And it was good to hear an entire presentation
 about SQL without once (that I can recall) hearing it pronounced sequel.
 :)

 ___
 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] working checkout does not match what would have ended up in the repository

2014-05-31 Thread B Harder

Stephan - i'm on mobile ATM so will be brief, but you and I did discussed
this offline weeks ago whereby I thought we agreed that changing the text
of the initial commit to something symbolic (.?) or inoffensive Latin
(seed , origin) really would fit the bill without rejigging core fossil
operations. If you beat me to it, feel free to post the gist of our
conversation. I am (and have been) with drh on this: it's sort of silly,
and causing much more grief than its worth. At best this should be in a 
no_origin (or whatever one calls this feature) branch, and hopefully a
non-default option if it moves to trunk.
On May 31, 2014 7:33 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Sat, May 31, 2014 at 1:21 PM, Richard Hipp d...@sqlite.org wrote:

 Can somebody please explain to me what this change accomplishes, other
 that introduce needless bugs, which it seems to excel at?  What problem
 does it solve?  Why shouldn't we back it out?


 It doesn't solve a problem so much as open up a minor new feature (the
 ability to have all commit messages in one's preferred language). i would
 personally like to see it kept (mainly for future compatibility with
 libfossil, which doesn't require an initial checkin ;), but not as the
 default. The default should stay as it historically has been - creating the
 hard-coded empty commit.

 Once i'm back from shopping i'll work on a patch which reverts to the
 previous default behaviour and adds a new flag for those who want to
 create/play with an empty repo (which still likely has open corner cases
 involving RID 0).

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 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] Git horror story post.

2014-05-31 Thread B Harder

http://mikegerwitz.com/papers/git-horror-story
___
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] working with open source code

2014-05-30 Thread B Harder

IIUC:

you: fossil clone http://sqlite.org:8080 fossils/sqlite.fsl; cd
project_dir; fossil open ~/project_dir/sqlite.fsl; fossil server

Each of your our co-conspirators: fossil clone
http://your.machine.address:8080 fossils/sqlite.fsl; cd project_dir; fossil
open ~/fossils/sqlite.fsl

You will: fossil set autosync 0 (because unlikely drh is going to let you
push your changes to canonical repo)

Your co-conspirators will set autosync to 1 (to sync with your repo
auto-magically).

You will use the UI to give (eg) developer privileges to the folks that
cloned from you, so they can re-push their work to your copy of the repo.

Hack, hack. fossil sync, fossil pull, fossil push where necessary. Maybe
two peers will sync explicitly between themselves if they're working on
something that requires it...

What am I missing?
On May 30, 2014 9:42 PM, Abilio Marques amarq...@smartappsla.com wrote:

 Hi,

 Let's say I want to do this setup:
 Clone sqlite repo on a local server
 Then clone the server into several machines, with the users pushing changes

 Then, someday, I will want to update my sqlite base code.

 In git, one would first fork the code from another repo, add a second
 remote:
 git remote add upstream

 then proceed to work as usual. Then do a:
 git fetch upstream

 and even a merge:
 git merge upstream/master


 Any recomendation on how to perform something like this, for example, with
 the sqlite code?


 Thanks,


 PS: just in case https://help.github.com/articles/fork-a-repo
 https://help.github.com/articles/fork-a-repo

 ___
 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] Autosync retry?

2014-05-29 Thread B Harder

I was going to +1 sbeals idea, but the pull-only autosync note came up, and
now I think I may not know all there is about autosync. Thanks for keeping
it interesting, folks.
On May 29, 2014 8:34 PM, Andy Bradford amb-fos...@bradfords.org wrote:

 Thus said Stephan Beal on Thu, 29 May 2014 22:10:24 +0200:

  Wasn't even  aware of pull-only  until earlier today. i  am completely
  ambivalent on the topic - never  had any problems with autosync - this
  was just what came to mind  when you posted. Seemed easier than adding
  a new option, but was not aware  of the pull-only feature (so a second
  option might be simpler).

 Actually, I thought  it was a great idea except  that it conflicted with
 pull-only. I agree that it will be simpler as a separate setting:


 http://www.fossil-scm.org/index.html/info/7653ab63420e4ab4ca6372a53de9314a18e1b946

 It will default to  1 so it retains the same  behavior as Fossil without
 the setting. Setting  it greater than 1 allows those  who want Fossil to
 try harder to get more tries. Autosync (on/off) itself is still governed
 by the autosync setting.

 Andy
 --
 TAI64 timestamp: 40005387fc6d


 ___
 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] Excluding [brackets] from a.../a links

2014-05-14 Thread B Harder

Andy, to be clear, are you suggesting:

  a) blah blah [a href=somethingcafebabe/a] blah blah blah

  b) blah blah a href=somethingcafebabe/a blah blah blah

?

-bch


On 5/14/14, Joseph Prostko joe.pros...@gmail.com wrote:
 On Wed, May 14, 2014 at 2:38 PM, Andy Goth andrew.m.g...@gmail.com wrote:
 I'd like for the [bracket] characters to not be part of the a.../a
 links
 in Fossil web pages, at least when the link text is an artifact ID.  This
 change would make it easier to highlight just the artifact ID and omit
 the
 brackets so that I can paste it elsewhere without having to then delete
 the
 brackets manually.  Most web browsers make it very hard to start
 highlighting in the middle of link text, as they choose to interpret that
 as
 dragging an object.

 I've encountered the problem you mentioned about highlighting, but
 admit I'm not sure if I'd like to see the brackets go away.  I almost
 think it would still look cleaner with them present.  That said, I'd
 love if somebody could assemble a side-by-side image showing the
 difference, as I admit my curiosity is piqued as to how it would
 actually look.  :)

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



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Excluding [brackets] from a.../a links

2014-05-14 Thread B Harder

That's what I was imagining/hoping too, but I'm not sure if that was
original proposal. I like the way the [ ] set off the string we
care about, but then I wondered if the ease of select/copy was because
the brackets were completely eliminated.

-bch


On 5/14/14, Stephan Beal sgb...@googlemail.com wrote:
 On Wed, May 14, 2014 at 11:22 PM, B Harder brad.har...@gmail.com wrote:

 Andy, to be clear, are you suggesting:

   a) blah blah [a href=somethingcafebabe/a] blah blah blah


 My comments assumed this interpretation. To my eyes that looks a tiny bit
 cleaner, but i won't argue strongly one way or the other.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] RFC: primitive interactive add/rm/commit/diff

2014-05-09 Thread B Harder

The $EDITOR idea is the first thing I thought of when reading the
Stephens initial post. Low barrier to entry, high effort/reward ratio.

A curses interface would be sexy (for some definition), but I'd say a
distant second as far as functional desirability.

-bch


On 5/7/14, Stephan Beal sgb...@googlemail.com wrote:
 On Wed, May 7, 2014 at 10:56 PM, Michai Ramakers
 m.ramak...@gmail.comwrote:

 On 7 May 2014 22:51, Stephan Beal sgb...@googlemail.com wrote:
  Maybe output the list and confirm for Y/n as it does now for certain
  scenarios?

 I don't think I understand... I meant undo/redo as per editor
 features, within a single select-files-to-operate-on editor session.
 ('removed filename' as in, removed the actual name from the initial
 list of chown files)


 i misunderstood your point about undo/redo. i only meant show the user the
 proposed list and allow them to confirm it, hopefully cutting down on the
 need to undo in the fossil sense.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby
 Wolf



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Trouble when making new repository

2014-05-08 Thread B Harder

I restrained myself in the previous discussion that ended up being about
the initial empty commit, but now I feel compelled: the rational,
discussion, and decision to remove the initial empty commit were pretty
poor, IMO. I don't want to belabor the point, so I'll leave it at that.

Happy to discuss or be corrected.
On May 8, 2014 1:03 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Thu, May 8, 2014 at 9:57 PM, Stephan Beal sgb...@googlemail.comwrote:

 Going back a version does indeed fix it. i'll roll back that commit, as
 soon as i figure out what the proper approach is to rolling back a commit.
 (Suggestions welcomed ;)


 i always forget about move to new branch...

 Richard just moved it.

 Trunk works again.


 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal
 Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
 those who insist on a perfect world, freedom will have to do. -- Bigby Wolf

 ___
 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] Merging two leaves not on the same graph?

2014-05-01 Thread B Harder

I think that initial empty commits went in at my request. Iirc, so I could
have related (but not inheriting from trunk) vendor branches. Can we
review/discuss before axing?
On May 1, 2014 1:06 AM, Jan Nijtmans jan.nijtm...@gmail.com wrote:

 2014-05-01 7:24 GMT+02:00 Gerald Gutierrez gerald.gutier...@gmail.com:
  So now I'm confused. Should/can I merge these two leaves, or just leave
 it
  alone, or is the repository now in an inconsistent state?

 The only way I see to get rid of the second 'initial empty commit' is by
 logging in as admin and 'shun' the artifact directly. (dangerous!!!).
 The repository is not in an inconsistent state, it's just confusing.

 I think it would be better if fossil didn't create the initial empty
 commit any more:
 http://fossil-scm.org/index.html/info/f2c8b4f375
 That would avoid the confusion, and it works fine!

 Any objections merging this to trunk?

 Regards,
   Jan Nijtmans
 ___
 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] Suggestion about fossil commit

2014-04-14 Thread B Harder

That sounds like a bad idea to me. IMO, this is a case of good enough
getting in the way of good as far as solutions to your annoyance.

Off the top of my head, I can think of two workflow habits that may help
you:

1) set up/turn on gpg signing, so you'll be required to sign commits before
they're actually applied.
2) do not use -m, but let fossil through you into the default editor to
type your commit message interactively. There are interesting articles on
git commit messages that dovetails with this problem, too, which may add
even further value [0] [1]. Currently, by default, I think we're not really
setup to take advantage of the advice in the articles, but (to my mind) it
sounds like a great place to be, and getting there (directly via canonical
fossil, or libfossil or other tool) is really easy to imagine.

-bch

[0]
http://stackoverflow.com/questions/15324900/standard-to-follow-when-writing-git-commit-messages

[1] http://robots.thoughtbot.com/5-useful-tips-for-a-better-commit-message
On Apr 13, 2014 4:41 PM, Stanislav Paskalev ksh...@gmail.com wrote:

Hi fossil-devs,
I often reuse a console to work with fossil as well as something else
(e.g. compile, run tests, etc)

Due to my trigger-happy fingers I've had quite a few cases where
I inadvertently ran fossil commit -m .. from history when in reality I
wanted to run my tests for example.

Fossil could compare the current message against the latest checkin in the
active branch and warn if they match. If this sounds fine - I can make and
send a patch :)

Regards,
Stanislav Paskalev

___
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] Suggestion about fossil commit

2014-04-14 Thread B Harder

On 4/14/14, Martin Gagnon eme...@gmail.com wrote:
 Le 14 avr. 2014 11:48, Stephan Beal sgb...@googlemail.com a écrit :

 On Mon, Apr 14, 2014 at 3:39 PM, Tony Papadimitriou to...@acm.org
 wrote:

 But, in my defense, (and I just re-read it to be sure I didn't miss it)
 nowhere in the help documentation (FOSSIL HELP COMMIT) or the comment in
 the editor (# Enter commit message for this check-in. Lines beginning with
 # are ignored.) does it say, or even imply, that an empty comment is one of
 the reasons that will 'abort' the commit.

 LOL!!!


 If i'm not mistaken, svn does the same thing (but i haven't got an svn
 with changes to try it out at the moment). Possibly even git - most SCMs do
 not like the users to enter empty commit messages.

 Even the famous CVS does the same...

Our users shouldn't need CVS, SVN, etc experience to know this. I
added documentation to clarify.

 --
 Martin G.



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Suggestion about fossil commit

2014-04-14 Thread B Harder

On 4/14/14, David Given d...@cowlark.com wrote:
 On 4/14/14, 9:31 PM, B Harder wrote:
 [...]
 Our users shouldn't need CVS, SVN, etc experience to know this. I
 added documentation to clarify.

 It might also be useful to add:

 # (To abort the commit, leave this file unchanged)

 ...to the commit message, too.

+1, done.

New_Version: 0484ccf2e9335e2f4c9914afabe7d66c28b0be99

-- 
Brad Harder
Method Logic Digital Consulting
http://twitter.com/bcharder
___
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] TH1: support for octal and hexadecimal numbers in expressions

2014-04-04 Thread B Harder

I think th1 happens to basically be a subset of Tcl, but is not
designed to strictly be a subset of Tcl, fwiw.

On 4/4/14, Jan Nijtmans jan.nijtm...@gmail.com wrote:
 2014-04-04 10:54 GMT+02:00 Mark Janssen mpc.jans...@gmail.com:
 Why can't n-ary numbers have dots? 0b1.11 is a perfectly valid
 representation of 1.75.

 $ tclsh8.6
 % expr 0+0b1.1
 missing operator at _@_
 in expression 0+0b1_@_.1
 %

 Since th1 is supposed to be a subset of Tcl, I don't think
 that th1 should invent any syntax which Tcl doesn't support.
 (Feel free to write a Tcl TIP, but I don't think it has a high
 chance to be accepted.)

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



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Database locked, but which?

2014-01-14 Thread B Harder

On 1/14/14, Andy Bradford amb-fos...@bradfords.org wrote:
 Hello,

 While attempting to pull the Fossil repository, I saw this error:

 $ fossil up
 Autosync:  https://www.fossil-scm.org/
 Round-trips: 2   Artifacts sent: 0  received: 0
 Error: Database error: database is locked: {UPDATE event SET mtime=(SELECT
 m1 FROM time_fudge WHERE mid=objid) WHERE objid IN (SELECT mid FROM
 time_fudge);}
 Round-trips: 2   Artifacts sent: 0  received: 0
 Pull finished with 1346 bytes sent, 1866 bytes received
 Autosync failed

 Rerunning the  command was successful. Is  this normal? I have  no other
 fossil command running, so the error must have come from remote.

 $ fossil version
 This is fossil version 1.28 [4699f8d919] 2014-01-14 10:43:23 UTC

No pending commits in other windows? (ie: waiting for you to enter
password for gpg key) ?

-bch

 Thanks,

 Andy
 --
 TAI64 timestamp: 400052d60237


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



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] New Tree-View feature requires newer sqlite.

2014-01-02 Thread B Harder

_WHY_ does --disable-internal-sqlite (and the unknown versions of
SQLite that follow) have to be supported ?

If package/OS maintainers insist on hacking in alien shared-lib
SQLite, let them own their hacks and the repercussions.

Call it a major version# bump, and remove that support.

-bch

On 1/2/14, Richard Hipp d...@sqlite.org wrote:
 The silly requirement of some distributions that *everything* must be a
 shared library irks me beyond words.  I hate having to support
 --disable-internal-sqlite, and I hate having to add silly work-arounds in
 the code to accommodate distributions trying to use an older SQLite with a
 newer Fossil.  This impedes progress and introduces bugs.  It's a lose-lose
 situation.  And yet the distributions are dogmatic on this point.

 It's maddening.  It makes my hair turn gray.  It irks me more than seeing
 the noun data used as a plural.  Utter madness!

 But we live in a fallen world.  We have to do it.  Please go ahead and
 merge.



 On Thu, Jan 2, 2014 at 10:33 AM, Jan Nijtmans
 jan.nijtm...@gmail.comwrote:

 2014/1/1 Andy Bradford amb-fos...@bradfords.org:
  ...I get this because I configure with --disable-internal-sqlite
  on OpenBSD.

 Fixed here:
 http://fossil-scm.org/index.html/info/c3211392da

 The branch timeline-utc contains another
 --disable-internal-sqlite - related fix (making
 the timeline-utc option work). Before
 merging this to trunk I would like some
 more pairs of eyes having a look at it.

 Anyone?

 Many thanks!
Jan Nijtmans
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




 --
 D. Richard Hipp
 d...@sqlite.org



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Parent of the very first checkin?

2013-12-20 Thread B Harder

If I understand what you're looking for (first empty commit?), when I asked
this question some time ago, somebody suggested I just tag it myself.
Simple solution, Just Works.
On Dec 20, 2013 8:54 PM, Andy Bradford amb-fos...@bradfords.org wrote:

 Thus said Richard Hipp on Fri, 20 Dec 2013 19:05:07 -0500:

  http://www.fossil-scm.org/fossil/info/a28c83647d

 Is there a  command line option that will find  this artifact? I thought
 perhaps the root:trunk symbolic name would  find it, but I was wrong. It
 finds c06edd231fc15d145a1c96c39b8fecdb79b33523 which is apparently where
 the current trunk began from a branch.

 Of course  the following  works, but I  have to guess  at the  number of
 artifacts:

 fossil timeline -n 10 | tail

 Thanks,

 Andy
 --
 TAI64 timestamp: 400052b51f20


 ___
 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] Breakthrough! [was Re: missing branch tag (?)]

2013-10-10 Thread B Harder

hrmmm... interesting.

I was getting no common ancestor.

I closed that repo to mail it. You did you testing (successfully). I
re-opened the repo to replicate my results, and in fact it worked
fine.

If you (anybody) have the time, would you create a repo and go through
the ~10 steps manually and see what happens?

What I was concentrating on is:

[vendor] is branched off initial emtpy ci
[feature] is branched off [trunk]
[feature] -[vendor] before [trunk] - [vendor]
[feature] - [trunk] then fails w/ no common ancestors

Now, out of curiosity I'm going to close/open my test/clone problem repo.


On 10/10/13, Stephan Beal sgb...@googlemail.com wrote:
 On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote:

 Breakthrough!

  I have a minimal(ish) example of a repo that is broken:

 Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge
 [trunk].


 i end up with:

 http://www.wanderinghorse.net/tmp/brad-broke.png

 which is what i would expect? (Of course i had to lie and say i was user
 bch.)


 This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Breakthrough! [was Re: missing branch tag (?)]

2013-10-10 Thread B Harder

closed/opened my more complex real-world problem repo and problem still exists.

On 10/10/13, B Harder brad.har...@gmail.com wrote:
 hrmmm... interesting.

 I was getting no common ancestor.

 I closed that repo to mail it. You did you testing (successfully). I
 re-opened the repo to replicate my results, and in fact it worked
 fine.

 If you (anybody) have the time, would you create a repo and go through
 the ~10 steps manually and see what happens?

 What I was concentrating on is:

 [vendor] is branched off initial emtpy ci
 [feature] is branched off [trunk]
 [feature] -[vendor] before [trunk] - [vendor]
 [feature] - [trunk] then fails w/ no common ancestors

 Now, out of curiosity I'm going to close/open my test/clone problem repo.


 On 10/10/13, Stephan Beal sgb...@googlemail.com wrote:
 On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote:

 Breakthrough!

  I have a minimal(ish) example of a repo that is broken:

 Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge
 [trunk].


 i end up with:

 http://www.wanderinghorse.net/tmp/brad-broke.png

 which is what i would expect? (Of course i had to lie and say i was user
 bch.)


 This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal



 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Breakthrough! [was Re: missing branch tag (?)]

2013-10-10 Thread B Harder

WARNING - no common ancestor: somefile
WARNING - no common ancestor: someotherfile
WARNING - no common ancestor: anotherfile
...


On 10/10/13, B Harder brad.har...@gmail.com wrote:
 closed/opened my more complex real-world problem repo and problem still
 exists.

 On 10/10/13, B Harder brad.har...@gmail.com wrote:
 hrmmm... interesting.

 I was getting no common ancestor.

 I closed that repo to mail it. You did you testing (successfully). I
 re-opened the repo to replicate my results, and in fact it worked
 fine.

 If you (anybody) have the time, would you create a repo and go through
 the ~10 steps manually and see what happens?

 What I was concentrating on is:

 [vendor] is branched off initial emtpy ci
 [feature] is branched off [trunk]
 [feature] -[vendor] before [trunk] - [vendor]
 [feature] - [trunk] then fails w/ no common ancestors

 Now, out of curiosity I'm going to close/open my test/clone problem
 repo.


 On 10/10/13, Stephan Beal sgb...@googlemail.com wrote:
 On Thu, Oct 10, 2013 at 7:31 PM, B Harder brad.har...@gmail.com wrote:

 Breakthrough!

  I have a minimal(ish) example of a repo that is broken:

 Take the attached (broken.fsl, 62K) repo, co [vendor], and try to merge
 [trunk].


 i end up with:

 http://www.wanderinghorse.net/tmp/brad-broke.png

 which is what i would expect? (Of course i had to lie and say i was user
 bch.)


 This is fossil version 1.27 [4137f4cda9] 2013-09-26 08:09:03 UTC

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal



 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder



 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] missing branch tag (?)

2013-10-09 Thread B Harder

It appears that somehow the branch tag was deleted on my [trunk].

Now, when I try to merge from trunk - feature_branch, I get something like:


$ fossil merge trunk
WARNING - no common ancestor: filea.c
WARNING - no common ancestor: fileb.c
WARNING - no common ancestor: filec.c
...
ADDED src/otherfile_a.c
ADDED src/otherfile_b.c
ADDED src/otherfile_c.c

How can I restore the trunkness of trunk through its complete
timeline? I tried adding trunk tags, but I didn't suspect they'd
work, and I was correct.

-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] missing branch tag (?)

2013-10-09 Thread B Harder

I know what you're talking about, but I'm not seeing the results I hope for.

I've made a copy of the repo, and have teased out ea. commit/event
SHA1. I've run on ea. SHA1 fossil tag list --raw [sha1_id] and
collected that output[0].

The tags look like I'd expect (though I could be mistaken) and the web
rendering fits my same mental model... however, when I: fossil co
os_x and try to fossil merge trunk, it still fails...

Interestingly, I can checkout a certain os_x commit, and merge from
anywhere in trunk. The next os_x commit, though, fails. I didn't think
os_x tags were at issue, and they *look* sane to  me... am I
misinterpretting behaviour?


[0] Example commit/tag info

==
[3c239fe86a]
==
branch=os_x
sym-os_x
==

==
[8aa3d3239e]
==
tkt-537e90fb9d44b8091abd9d04667a66d241e7d13f
==

==
[5c5f613aa8]
==
branch=trunk
sym-trunk
==

==
[60d23a19c0]
==
branch=vendor
sym-vendor
==

==
[ae48737be6]
==
branch=os_x
sym-os_x
==

On 10/9/13, Mark Janssen mpc.jans...@gmail.com wrote:
 Branches are controlled by propagating raw tags. Start with fossil tag list
 --raw checkin. Then I think you should be able to cancel the offending raw
 tag.
 On 9 Oct 2013 23:07, B Harder brad.har...@gmail.com wrote:

 ...and now I see the edit where the trunk tag was cancelled --
 question remains --- can I undo/reverse the effect?

 On 10/9/13, B Harder brad.har...@gmail.com wrote:
  It appears that somehow the branch tag was deleted on my [trunk].
 
  Now, when I try to merge from trunk - feature_branch, I get something
  like:
 
 
  $ fossil merge trunk
  WARNING - no common ancestor: filea.c
  WARNING - no common ancestor: fileb.c
  WARNING - no common ancestor: filec.c
  ...
  ADDED src/otherfile_a.c
  ADDED src/otherfile_b.c
  ADDED src/otherfile_c.c
 
  How can I restore the trunkness of trunk through its complete
  timeline? I tried adding trunk tags, but I didn't suspect they'd
  work, and I was correct.
 
  --
  Brad Harder
  Method Logic Digital Consulting
  http://www.methodlogic.net/
  http://twitter.com/bcharder
 


 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] missing branch tag (?)

2013-10-09 Thread B Harder

Matt -

not a bad idea, though I'm not entirely sure where to proceed now.

What I think (hope?) I have is two branches:

trunk, and os_x

os_x originally branched off trunk (as all things do, in some form or another).

I've got an entry in os_x (an old one) where I can:

fossil co [old os_x entry]
fossil merge trunk

and everything appears to work fine. This is merging the very tip of
trunk, which I expect. Consider that operation only a proof of
concept; let's get rid of that merge (fossil revert), and :

fossil info, get the child of that good os_x current checkout.

fossil co [child-of-os_x]
fossil merge trunk
^ failure.

So, it appears to me that in the single transition from [good-os_x] to
[bad-os_x], something is amiss. I did have suspicious looking tagging
in [trunk], but perhaps that was a red herring in this matter. I'm at
a loss to wrap my head around where the child of a working checkout
can't merge the same as its parent. And where I *thought* it was
[trunk] that was at issue, now it could be (?) os_x ?

Flummoxed.

-bch

On 10/9/13, Matt Welland estifo...@gmail.com wrote:
 I've had something similar happen before and was able to fix it by using
 the ui to make a branch trunk in several nodes along the trunk timeline
 until one of them worked.  Try it disconnected do as not to mess up the
 original db.
 On Oct 9, 2013 3:26 PM, B Harder brad.har...@gmail.com wrote:

 I know what you're talking about, but I'm not seeing the results I hope
 for.

 I've made a copy of the repo, and have teased out ea. commit/event
 SHA1. I've run on ea. SHA1 fossil tag list --raw [sha1_id] and
 collected that output[0].

 The tags look like I'd expect (though I could be mistaken) and the web
 rendering fits my same mental model... however, when I: fossil co
 os_x and try to fossil merge trunk, it still fails...

 Interestingly, I can checkout a certain os_x commit, and merge from
 anywhere in trunk. The next os_x commit, though, fails. I didn't think
 os_x tags were at issue, and they *look* sane to  me... am I
 misinterpretting behaviour?


 [0] Example commit/tag info

 ==
 [3c239fe86a]
 ==
 branch=os_x
 sym-os_x
 ==

 ==
 [8aa3d3239e]
 ==
 tkt-537e90fb9d44b8091abd9d04667a66d241e7d13f
 ==

 ==
 [5c5f613aa8]
 ==
 branch=trunk
 sym-trunk
 ==

 ==
 [60d23a19c0]
 ==
 branch=vendor
 sym-vendor
 ==

 ==
 [ae48737be6]
 ==
 branch=os_x
 sym-os_x
 ==

 On 10/9/13, Mark Janssen mpc.jans...@gmail.com wrote:
  Branches are controlled by propagating raw tags. Start with fossil tag
 list
  --raw checkin. Then I think you should be able to cancel the offending
 raw
  tag.
  On 9 Oct 2013 23:07, B Harder brad.har...@gmail.com wrote:
 
  ...and now I see the edit where the trunk tag was cancelled --
  question remains --- can I undo/reverse the effect?
 
  On 10/9/13, B Harder brad.har...@gmail.com wrote:
   It appears that somehow the branch tag was deleted on my [trunk].
  
   Now, when I try to merge from trunk - feature_branch, I get
   something
   like:
  
  
   $ fossil merge trunk
   WARNING - no common ancestor: filea.c
   WARNING - no common ancestor: fileb.c
   WARNING - no common ancestor: filec.c
   ...
   ADDED src/otherfile_a.c
   ADDED src/otherfile_b.c
   ADDED src/otherfile_c.c
  
   How can I restore the trunkness of trunk through its complete
   timeline? I tried adding trunk tags, but I didn't suspect they'd
   work, and I was correct.
  
   --
   Brad Harder
   Method Logic Digital Consulting
   http://www.methodlogic.net/
   http://twitter.com/bcharder
  
 
 
  --
  Brad Harder
  Method Logic Digital Consulting
  http://www.methodlogic.net/
  http://twitter.com/bcharder
  ___
  fossil-users mailing list
  fossil-users@lists.fossil-scm.org
  http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
 
 


 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users




-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Anecdote regarding permissions tracking in Fossil

2013-09-19 Thread B Harder

On Sep 19, 2013 1:38 AM, Stephan Beal sgb...@googlemail.com wrote:

 Hi, all,

 some people have bemoaned Fossil's lack of file permissions support over
the years. Initially, Fossil did not track _any_ permissions, but the
executable bit was eventually added because it is common practice to have
an executable configure script in the source tree.

 What i didn't know, though, is that git doesn't, either. i always assumed
git can do anything except except for making me a happy user.

 To quote the GIT Pocket Guide from O'Reilly[1]:

 Originally, Git saved and restored the full permissions on files (all
the mode bits). Later, however, this was deemed to cause more trouble than
it was worth, so the interpretation of the mode bits ... was changed ...
the only valid values for the low 12 bits of the mode... are octal 755 and
644, and these simply indicate that the file should be executable or not...
the actual mode value may be different depending on your umask setting...

And that's why we

1) trust our good judgment, the judgment of our fellow fossil developers,
and discuss these sorts of things rather than blindly doing what git does

2) don't conflate a version controlled repository with a release.

 [1] http://shop.oreilly.com/product/0636920024972.do

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Autosync: Too bad git doesn't have it...

2013-09-12 Thread B Harder

I read this roughly (in fossil-speak) as:

I had a bunch of email notes from folks requesting I merge their
feature-branches into my main branch, but my machine crashed and my mail
isn't accessible…

I think auto-sync wouldn't have saved anything, but perhaps the something
like fossils built-in ticket system where communiqués are first-class
objects could have helped, versus out-of-band email.
On Sep 11, 2013 4:34 PM, Richard Hipp d...@sqlite.org wrote:

 It appears that autosync would have saved Linus Torvalds from losing some
 work yesterday.  See
 http://lkml.indiana.edu/hypermail/linux/kernel/1309.1/01669.html for
 details.  Bummer.

 --
 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] RFC before trunking 'usage' command

2013-09-11 Thread B Harder

fossil set tracker [on|off] ?
On Sep 11, 2013 2:32 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Wed, Sep 11, 2013 at 11:26 PM, Kees Nuyt k.n...@zonnet.nl wrote:

 I wouldn't mind logging the arguments as well, especially for commands
 that modify the repository or a stash.


 i considered it, but the code overhead just wasn't worth it at that time
 of night. One of these days i'll miss having that, add it, and add a
 -verbose option which also shows the args.


 I wouldn't be interested in logging query-class commands, like
 fossil ls, fossil status, fossil timeline


 Do you mean the SQL code itself? If so, try:

 f time -n 1 -sqltrace

 One can learn a lot about how fossil works by using that.

 usage - commandtrace or commandhistory or cmdtrace or cmdhistory


 i think 3 of those might mess up the column alignment in 'help' ;).


 Note: on Linux/unix, it doesn't add much,
   history [-OPTIONS] | grep fossil
 will do fine, on MS Windows, I think it really adds value.


 Me, too, but i'm aware that many other people have much greater concerns
 regarding any sort of usage protocols. For me it's harmless, but it's not
 just about me.

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] database disk image is malformed?

2013-08-30 Thread B Harder

Richard, your service on all this is exemplary -- anybody who gives
you grief over this should just take a moment and reflect on all
you've done, and the remarkable stability and service we've all
enjoyed for so long.

If you want to punt and just have accounts recreated, I'm personally
fine w/ that, if it's an option.

Cheers,

-bch

On 8/29/13, Richard Hipp d...@sqlite.org wrote:
 On Fri, Aug 30, 2013 at 12:35 AM, B Harder brad.har...@gmail.com wrote:

 I don't know what the definition of recent is, but I think my password
 is same for months, wasn't working at time I sent last msg. I'll work
 with
 you off-list if necessary.


 I'm still working on the problem.  I'll get it fixed as quickly as I can.
 Sorry for the inconvenience.

 --
 D. Richard Hipp
 d...@sqlite.org



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] database disk image is malformed?

2013-08-29 Thread B Harder

Did this nuke accounts/passwords ?

On 8/29/13, Richard Hipp d...@sqlite.org wrote:
 On Thu, Aug 29, 2013 at 5:33 PM, Joerg Sonnenberger
 jo...@britannica.bec.de
 wrote:

 On Thu, Aug 29, 2013 at 04:50:19PM -0400, Richard Hipp wrote:
  The database corruption was caused by scenario 1.1 at
  http://www.sqlite.org/howtocorrupt.html.
 
  Apparently, file descriptor 2 was closed.

 The question for me would be why. That should not happen and any code
 should at most re-open fd 2 as /dev/null...


 That is a question I've been looking into but do not yet have an answer
 for.

 --
 D. Richard Hipp
 d...@sqlite.org



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] database disk image is malformed?

2013-08-29 Thread B Harder

I don't know what the definition of recent is, but I think my password is
same for months, wasn't working at time I sent last msg. I'll work with you
off-list if necessary.

Thanks drh,

-bch
On Aug 29, 2013 8:12 PM, Richard Hipp d...@sqlite.org wrote:




 On Thu, Aug 29, 2013 at 10:59 PM, B Harder brad.har...@gmail.com wrote:

 Did this nuke accounts/passwords ?


 Possibly.  I restored from backup.  But if passwords changed recently, the
 backup might have missed them.


 --
 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] Bikeshedding opportunity: back to the topic of libfossil's name

2013-08-21 Thread B Harder

Agreed. Hyphens in libnames don't look pleasing to my eye (fwiw),
libfossilscm (cc ... -lfossilscm ...) might be next best to
disambiguate from potential collision w/ another libfossil, though it
too is pretty ugly looking.

Brief search yields https://github.com/paulfitz/libfossil as second
hit (after this very discussion). I also searched for libfsl, which
appears to be claimed, I didn't look into what that project is.

-bch

On 8/21/13, Chad Perrin c...@apotheon.net wrote:
 On Wed, Aug 21, 2013 at 07:45:53PM +0200, Stephan Beal wrote:
 On Wed, Aug 21, 2013 at 7:43 PM, Mark Janssen mpc.jans...@gmail.com
 wrote:
 
  +1 for libfossil. I hate it when libraries have smart names requiring
  me
  to google for the package name to install.

 BTW (should have noted this earlier): there is a filesystem called
 fossil, and while i have not found a libfossil naming conflict
 (==cursor
 googling), there might potentially be one, which is why i eventually
 tagged
 -scm to the name. But, again, i'm not emotionally attached to that. In
 fact, the name doesn't have to contain fossil, but i assume that'd be
 easier for everyone.

 I definitely vote for the name libfossil.  In fact, if you don't use it,
 I might have to encourage another Fossil library effort just so there's
 a libfossil that everyone will be able to find and remember.

 --
 Chad Perrin [ original content licensed OWL: http://owl.apotheon.org ]
 ___
 fossil-users mailing list
 fossil-users@lists.fossil-scm.org
 http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] commits from host A sometimes not seen on B

2013-08-20 Thread B Harder

On Aug 20, 2013 8:25 PM, Donny Ward donnyjw...@gmail.com wrote:

 Hey Richard,

 I get the same problem every once in awhile. Many times actually. I
consider myself a heavy fossil user. My most active repository has 1087
checkins all made by me.

 I once submitted a ticket about it here:
http://www.fossil-scm.org/xfer/tktview/f7879271cf4182d2?plaintext

 I have not noticed a pattern with the syncing problems. Going by feel, it
feels like it occurs most frequently when I create a new branch, or if I
edit a check-in comment.

 Also keep in mind that I rarely if ever have had sync errors. After
every commit I would look at the remote repository to see if all the
changes synced and they always do, except for these few cases.

 Also note that I always have auto-sync turned on. I used to host my
repositories on a Linux VPS. I have since moved to Chisel and still have
encountered sync problems. One time when the problem occured on my Linux
VPS, I solved the problem by rebuilding the repository on the VPS side (the
host repository). I dug around the source code of Fossil briefly to try
and figure out the problem, and while I did not pinpoint it, I believed at
the time that the issue had to do with the usage of clustered and
unclustered artifacts. If I understand correctly, the used of these
clusters is for a syncing optimization. However once I saw that you
committed the --verily option, I stopped pursuing the problem because I was
fairly confident that --verily solves the issue. Since my repository is
hosted on Chisel, I will not find out until the next version is released
and Chisel updates to that version.

 Also note that in ALL cases, the syncing problem can be solved by
recloning the host repository. But I would prefer not to do that every
time. I only used the fossil rebuild solution one time so I can't
confidently say that it fixed the problem. And since I can't rebuild
repositories on Chisel I can't try it with my current syncing problem.

 The problems have occured with and without HTTPS.

 So right now I actually have the syncing problem again. I created a new
branch where I committed the entire source code to FreeType. This was done
in a Linux VM. I then went to my Windows 8 desktop to update (keep in mind
I have autosync always on) and it failed to pull the new branch; it's
missing entirely from the timeline. It's also missing from my Macbook as
well.

 So Mr. Hipp if you're interested, I can send you a copies of my
repository to analyze and debug. However I would also need to get the
current maintainer of Chisel to email me an untouched copy of my repository
as it exists on that site right now. Does anyone have contact info for
Chisel? The site still has James Turner's name on it.

I think Andreas Kupries is the gentleman you want: andre...@activestate.com

 I would very much like for this bug to be fixed. Though --verily looks
promising.

 Donny Ward

 ___
 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] New user request

2013-08-11 Thread B Harder

Very glad you like it.
On Aug 10, 2013 10:55 PM, Sam Sellars philosopher@gmail.com wrote:

 Thank you sir!  This is exactly the type of thing I am looking for.  I
 appreciate the time you put into this.


 —

 Hi Sam.

 Welcome aboard. I think Fossil is excellent, and I hope you will too.

 I'm typing on a mobile device ATM, so please excuse the brevity and
 spelling errors.

 I use fossil for all my personal projects, as well as professionally. For
 personal projects, I make a project-specific dir under my project
 containing dir (~/work), such as ~/work/foo/, and create an out-of-tree
 repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open
 ../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor,
 ./test. Supporting third-party code goes into ./src/vendor/libawesome (for
 example), my own code goes into ./src, docs to ./doc, and tests to ./test.

 For an imaginary lib awesome project that I want to build against, I
 place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then
 commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch
 vendor

 For my own code, infrastructure, I go back to trunk (fossil co trunk),
 add my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.
 h.in) and do initial commit: fossil ci -m initial commit.

 If you feel you need/may patch your vendor code, you can: fossil co
 vendor; [hack hack hack]; fossil ci -m custom patches against lib awesome
 for project foo --branch vend_patched -- and maintain this along with
 upstream lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4
 code over 1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4

 Import to vend_patched: fossil co vend_patched; fossil merge vendor;
 [check for conflicts, correctness], fossil ci -m merge latest lib awesome
 1.2.4 from [vendor]

 Back to the code your writing yourself: fossil co trunk; fossil merge
 vend_patched; fossil ci -m import supporting vendor code; [hack hack
 hack]; fossil ci -m my useful commit msg here; [hack hack hack]

 ... now you (still on [trunk]) want to start on a potentially
 build-breaking experimental feature: a bunny themed widget set. Start
 hacking in bunny-code, but at first commit: fossil ci -m start of bunny
 conversion --branch hop_hop

 You've now got two branches that are interesting to you: current stable
 production in [trunk], and the Next Big Killer Feature (not ready for prime
 time), in hop_hop.

 You hack on [hop_hop] (which is a derivative of [trunk], and improve it.
 Along the way though, your boss says: I've heard lowercase is the new
 black; make all the dialogue in our current project lowercase. No title
 case, upper case, camel case... All user facing text is lowercase.

 [hop_hop] is still WIP (work in progress), not ready for public
 consumption, so you go back to [trunk] (which you are shipping). You're in
 the middle of hacking [hop_hop], and you're not really ready to commit, but
 you don't want to lose your work. No problem. Stash it. fossil stash add -m
 hop_hop fluffy tail feature - incomplete

 Your work is safe in a stash that is shared among all branches, and you
 have no pending commits in your working set (you just stashed it, and when
 that partial work was stashed, the pertinent files were reverted to the
 state of the last commit.)

 You prepare to start lowercasing: fossil co truck; [hack hack hack];
 fossil ci -m lowercase here, lowercase there, and change all user
 dialogue, etc to lowercase, committing as you convert. You tag a new
 release: fossil tag add foo_5.4.3 trunk, notify q/a and release
 management, and get back to bunny hacking.

 fossil co hop_hop

 You start making a game plan for finishing fluffy tail feature, when you
 realize that the super-awesome lowercasing you just finished isn't in your
 hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for
 conflicts, nice importing]; fossil ci -m import lowercase excellence from
 [foo_5.4.3]

 Now, pick up your partial fluffy tail implementation: fossil stash pop
 (pops last stashed item like a stack operation), and you're ready to finish
 your interrupted coding and finish bunnifying. As you finish coding and
 commit, your boss comes up and says: What have you been working on these
 last 3 weeks? I'll show you, you say!

 fossil server

 [Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/

 You are taken to the Foo Project Repository homepage, and from there you
 browse the timeline which has a pretty layout of each commit, each branch,
 each merge, each tag... Your boss is impressed.

 I'm impressed. But I want to give you some feature requests we've
 collected from clients. Would you like them as a crumpled collection of
 post it notes, or some other format?

 You say: Point your IE4 browser to 192.168.0.99:8080/, log in as
 superboss like I showed you, and add each item as a feature-request
 ticket, so we can all see the requests, and their state, and append notes
 to each

Re: [fossil-users] New user request

2013-08-08 Thread B Harder

Hi Sam.

Welcome aboard. I think Fossil is excellent, and I hope you will too.

I'm typing on a mobile device ATM, so please excuse the brevity and
spelling errors.

I use fossil for all my personal projects, as well as professionally. For
personal projects, I make a project-specific dir under my project
containing dir (~/work), such as ~/work/foo/, and create an out-of-tree
repo: cd ~/work/foo; fossil new ../fossils/foo.fsl; fossil open
../fossils/foo.fsl . Then, in the project dir I make ./doc, ./src/vendor,
./test. Supporting third-party code goes into ./src/vendor/libawesome (for
example), my own code goes into ./src, docs to ./doc, and tests to ./test.

For an imaginary lib awesome project that I want to build against, I
place the code in ./src/vendor/libawesome, fossil add ./src/vendor, then
commit it to it's own branch: fossil ci -m libawesome v.1.2.3 --branch
vendor

For my own code, infrastructure, I go back to trunk (fossil co trunk), add
my files: (cd ~/work/foo; fossil add ./Smakefile ./src/*.c ./src/*.h.in)
and do initial commit: fossil ci -m initial commit.

If you feel you need/may patch your vendor code, you can: fossil co vendor;
[hack hack hack]; fossil ci -m custom patches against lib awesome for
project foo --branch vend_patched -- and maintain this along with upstream
lib awesome updates: fossil co vendor; [dump lib awesome v1.2.4 code over
1.2.3]; fossil ci -m update lib awesome 1.2.3 - 1.2.4

Import to vend_patched: fossil co vend_patched; fossil merge vendor; [check
for conflicts, correctness], fossil ci -m merge latest lib awesome 1.2.4
from [vendor]

Back to the code your writing yourself: fossil co trunk; fossil merge
vend_patched; fossil ci -m import supporting vendor code; [hack hack
hack]; fossil ci -m my useful commit msg here; [hack hack hack]

... now you (still on [trunk]) want to start on a potentially
build-breaking experimental feature: a bunny themed widget set. Start
hacking in bunny-code, but at first commit: fossil ci -m start of bunny
conversion --branch hop_hop

You've now got two branches that are interesting to you: current stable
production in [trunk], and the Next Big Killer Feature (not ready for prime
time), in hop_hop.

You hack on [hop_hop] (which is a derivative of [trunk], and improve it.
Along the way though, your boss says: I've heard lowercase is the new
black; make all the dialogue in our current project lowercase. No title
case, upper case, camel case... All user facing text is lowercase.

[hop_hop] is still WIP (work in progress), not ready for public
consumption, so you go back to [trunk] (which you are shipping). You're in
the middle of hacking [hop_hop], and you're not really ready to commit, but
you don't want to lose your work. No problem. Stash it. fossil stash add -m
hop_hop fluffy tail feature - incomplete

Your work is safe in a stash that is shared among all branches, and you
have no pending commits in your working set (you just stashed it, and when
that partial work was stashed, the pertinent files were reverted to the
state of the last commit.)

You prepare to start lowercasing: fossil co truck; [hack hack hack]; fossil
ci -m lowercase here, lowercase there, and change all user dialogue, etc
to lowercase, committing as you convert. You tag a new release: fossil tag
add foo_5.4.3 trunk, notify q/a and release management, and get back to
bunny hacking.

fossil co hop_hop

You start making a game plan for finishing fluffy tail feature, when you
realize that the super-awesome lowercasing you just finished isn't in your
hop_hop codebase. No problem: fossil merge foo_5.4.3; [check work for
conflicts, nice importing]; fossil ci -m import lowercase excellence from
[foo_5.4.3]

Now, pick up your partial fluffy tail implementation: fossil stash pop
(pops last stashed item like a stack operation), and you're ready to finish
your interrupted coding and finish bunnifying. As you finish coding and
commit, your boss comes up and says: What have you been working on these
last 3 weeks? I'll show you, you say!

fossil server

[Open Firefox or opera, or chrome, etc], http://127.0.0.1:8080/

You are taken to the Foo Project Repository homepage, and from there you
browse the timeline which has a pretty layout of each commit, each branch,
each merge, each tag... Your boss is impressed.

I'm impressed. But I want to give you some feature requests we've
collected from clients. Would you like them as a crumpled collection of
post it notes, or some other format?

You say: Point your IE4 browser to 192.168.0.99:8080/, log in as
superboss like I showed you, and add each item as a feature-request
ticket, so we can all see the requests, and their state, and append notes
to each feature as necessary.

OK, says your boss, a glob of post it notes trying to break out of their
pocket as they head back to the bosses computer to key in tickets...

I could go on (I think I will, later), but I'm tired and I'm wearing a hole
in my touch screen. I sure hope this provided some

Re: [fossil-users] few TODO items

2013-08-03 Thread B Harder

On Aug 3, 2013 7:09 AM, Stephan Beal sgb...@googlemail.com wrote:

 On Sat, Aug 3, 2013 at 3:36 PM, Gour g...@atmarama.net wrote:

 a) Search feature seems to be addressed, right?


 Yes.


 b) uncomit - ability to simply uncommit last commit which I'd do while
 still staying in my local repo and prior to pushing any changesets to
 the wilderness. It's simply tedious not to be able to fix simple/common
 mistakes and edit commit line is simply not enough. Any pending plan in
 regard?


 i _think_ that came up once before, but it hasn't been specifically
addressed, AFAIR.


 c) pushing/managing single branches - at the present moment the mantra
 is 'all or nothing' which is also quite inconvenient when one wants to
 have e.g. several experimental feature branches and merge (even rebase
 them to the main trunk) before pushing (some) to the upstream. Any work
 on it?


 One of the devs did some work on this a year or so ago, but i don't know
how that ended.

Sorry, on mobile and time constrained, but do private branches address this
in any way?

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Inofficial naming contest...

2013-07-31 Thread B Harder

I'm going to recycle a project name I've used before: urvogel (the first
bird), and suggest for its logo:
http://www.ucmp.berkeley.edu/diapsids/birds/archie2.jpg
On Jul 30, 2013 3:06 AM, Stephan Beal sgb...@googlemail.com wrote:

 Hi, all,

 As most of you know, work has begun on a prototype of what i unfortunately
 dubbed fossil v2. As it turns out, everything i want to do can be done on
 top of current repos, with no repo-level incompatibilities (so far, at
 least). That means it's not really v2, but instead provides an alternate
 interface for v1 repos[1]. So... in light of that insight i am looking for
 a new name for the prototype code and am hoping you guys have some nice
 ideas.

 Things to keep in mind while coming up with a name:

 a) this is in no way official. The prototype is just that, and an
 experiment. It's coming along nicely so far, and it can open repos, but not
 do much of anything useful (e.g. no writing to the db yet and no timeline -
 timeline's coming up shortly, though).

 b) i'm looking to name the library, not the application. In the grand Unix
 tradition, however, applications often inherit part of their name from the
 underlying framework or library, so the chosen name might end up sticking
 around a while.

 c) The name will likely determine the name of the main header and library
 files. So that's the prize for the best idea (by vote, but DRH and i get
 extra votes ;) - the winner will have chosen the names clients will see
 when they do:
   #include libfossil-or-whatever.h
 or:
   gcc ... -lfossil-or-whatever

 The obvious choices include:

 - libfossil - nothing wrong with that, IMO.
 - libfsl
 - flib - is already used by several projects
 - libdino
 - libname of some specific dinosaur species

 :-?


 [1] = http://fossil.wanderinghorse.net/repos/f2/

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Q: What Unix / Linux _DISTRIBUTIONS_ Does The Fossil Project Care About?

2013-07-30 Thread B Harder

I'd suggest: fossil is happy to run wherever it can, and strives for
portability wherever it can, whenever it makes sense.

Any OS is welcome to modify/redistribute fossil in the terms described in
the license.

It sounds to me (correct me if I'm wrong) you are asking what (or how
many?) operating systems are going to get special consideration? Likely,
the answer will be (as is the case with most open source software): Where
the interests of the developers lie.

For example, I'm interested in BSD (NetBSD specifically), and so I pay
attention to how fossil behaves on it. In terms of fixes then, when I
supply patches or bug reports, they are considered, and then appropriate
actions are taken (patches applied or rejected, changes made, or not). I
suspect most any other OS you're thinking of would receive the same
consideration.

-bch
On Jul 30, 2013 8:04 PM, Joseph R. Justice jayare...@gmail.com wrote:

 [Meta: This message is being intentionally sent to _both of_ the
 fossil-users and fossil-dev mailing lists, separately, so as to get the
 maximum possible feedback and response.  I am currently subscribed to both
 lists and will see any response you send to either of them.  You need not
 cross-post your response to both lists unless you deem it necessary to do
 so for some reason.  You can CC me or not in any response you send to a
 list.  If I've violated list custom by doing this, please flame me
 off-list.]

 [Meta: If you want to skip ahead to what I am proposing / offering to do,
 go to PROPOSED ACTION ITEM below.]



 Recently on the fossil-users mailing list, Stephan Beal 
 sgb...@googlemail.com started an extensive discussion thread titled
 Random thoughts on Fossil v2, which discussed among other things creating
 a library for core Fossil functionality (I'll refer to it as libfossil2)
 and one or more user-facing applications which would use this library to
 provide actual functionality (I'll refer to them collectively as
 fossil2client).

 In a response to his original post, I submitted some comments which, among
 other things, suggested things I thought should be done for such a
 hypothetical Fossil v2 so as to make it easier for a Unix / Linux
 Distribution to package and distribute the library and applications
 according to the standards and processes they normally use.  Some of the
 things I suggested along this line included:

 * Fossil2client not requiring or expecting libfossil2 to be compiled /
 linked into it statically, and that dynamic run-time linking be the
 expected norm;

 * The source for fossil2client not having an embedded copy of the source
 for libfossil2 incorporated within it;

 * (Unspoken here, but implicit, is that other libraries or sources for
 libraries, most specifically that for sqlite3, should not be compiled into
 the fossil2client statically or have a copy of its source incorporated into
 the source for fossil2client either);

 * Libfossil2 being implemented in such a way that multiple versions of it
 can be installed simultaneously on a given system, so that different
 clients can use different versions of libfossil2 if necessary and all
 successfully coexist on the system.

 * Otherwise doing things where possible to make it easier, or at least
 less difficult / inconvenient, for a Unix / Linux distribution to package
 and distribute libfossil2 and fossil2client.

 * In a later response, that amalgamation builds not be done or expected
 to be done.

 * Also somewhere along here that many of these things might well also
 apply to the existing fossil (v1) monolithic application, at least insofar
 as they represented things that Unix / Linux distributions would need to
 alter and/or undo so as to make that version of fossil conform to whatever
 their internal standards for the applications they distributed and
 supported happened to be.

 In Stephan's response to this, he commented in such a way that it seemed
 he at least believed that many Unix / Linux distributions wouldn't really
 care about these things, but would just follow the path of least resistance
 in terms of generating library and client binaries which they could then
 distribute to their end-users.  I want to emphasize that he did not come
 across as saying my suggestions were somehow wrong, but that he simply
 didn't see why anybody would bother doing things other than the easiest or
 default way as provided by the software as released by the Fossil Project.



 I believe he is mistaken about this, and that Unix / Linux distributions
 in general behave in a fashion significantly different than would an
 individual end-user running on Unix / Linux who was compiling fossil for
 their own personal or otherwise internal use.  I claim they do this because
 they are acting, albeit generally on a far smaller scale, as an operating
 system integrator, akin to what Microsoft does for Microsoft Windows or
 Apple does for MacOS/X, but also on a far larger scale in that they package
 and directly provide under

Re: [fossil-users] Any objections to renaming /stats_report...

2013-07-23 Thread B Harder

I personally have no objections, but as a matter of business and
visibility, perhaps do final last call for objections/alternatives! on a
business day.
On Jul 23, 2013 12:59 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Sun, Jul 21, 2013 at 7:49 PM, Richard Hipp d...@sqlite.org wrote:



 On Sun, Jul 21, 2013 at 11:42 AM, Stephan Beal sgb...@googlemail.comwrote:

 ... to /reports?

 the name /stats_report just seems cumbersome to me.


 I have no objections.  I suggest you want a few days and if you get no
 other replies, then make the change.


 @List: the countdown is running. Sometime this weekend /stats_report will
 be renamed to /reports unless someone comes up with a better name (consider
 that a challenge ;).

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Scripting in Fossil v2

2013-07-23 Thread B Harder

I think these things support each other. Specifically, with respect to Tcl
(and likely Guile, Lua), scripting support can come by embedding the Tcl
interpreter inside the app (ie: the standalone fossil executable), by
linking libtcl with fossil, and having fossil call into it appropriately.

Alternatively, one can take a library (ie: hypothetical libfossil), and
build bindings to it which satisfy loading those bindings/library into Tcl.
In this case, a Tcl script (or person at the keyboard) does the driving,
calling into fossil routines appropriately.

The first example would be Fossil with hooks, while the second would be
full scripting environment drives the operation, with full access to
fossil routines.

I'm personally more interested in the second. To my senses, it's more
dynamic, and I'd say lends itself to more rapid prototyping/testing,
accelerating the development of the fossil core itself. I think in terms of
Tcl, but this second approach also facilitates other languages
participating more than the first model does. Ie: if Perl wants to
participate, they write bindings against libfossil. If Ruby wants to
participate, they write bindings against libfossil, etc. In the first
model, to support multiple languages, you must necessarily fork fossil and
build out internal support within the fossil executable for Perl, in
another for support for Ruby, in another fork, support for Python, etc.

Does that make sense, or am I missing something?

-bch
On Jul 23, 2013 11:01 AM, Aaron W.Hsu arcf...@sacrideo.us wrote:

 Dear Stephan:

 With regards to scripting and fossil as a separate library, I actually see
 these as separate things. Having Fossil as a separate library allows other
 programs to use fossil capabilities, while any scripting interface, such as
 a public interface used to build shared objects that are dynamically linked
 at runtime by the Fossil program, allows Fossil to use the capabilities of
 other software. These are two different things. You don’t need to separate
 Fossil as a library in order to get a language agnostic extension interface
 for Fossil.


 Yours truly,

 Aaron W. Hsu


 --
 Aaron W. Hsu | arcf...@sacrideo.us | http://www.sacrideo.us

 *From:* Stephan Beal
 *Sent:* Tuesday, July 23, 2013 6:55 AM
 *To:* Fossil SCM user's discussion

 On Tue, Jul 23, 2013 at 12:51 PM, Laurens Van Houtven _...@lvh.io wrote:

 Not aimed at anyone in particular, but if you are going to suggest a
 particular language, can you please point to an interpreter that is easily
 embeddable into fossil? That seems to be the problem with at least JS and
 Python, and seems to be Lua's strong point. There's no point in discussing
 the relative merits of languages if we can't actually reasonably *use that
 language*.


 That's one of the beauties of restructuring fossil as a library: we don't
 need to embed any language at all. Instead, they can be built on top of the
 library. Yes, we'll want/need one standard interpreter for unit test
 purposes, but that will almost certainly end up being TCL or jimtcl,
 simply for reasons of historical momentum.

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil new bus error on Solaris 10 SPARC with gcc

2013-07-18 Thread B Harder

On 7/17/13, Edward Berner e...@bernerfam.com wrote:
 Hello,

 Using a recent trunk version of fossil, built with gcc on Solaris 10 on
 an UltraSPARC system, I get a bus error from fossil new:

 $ ./fossil new t.fossil
 Bus Error (core dumped)


 $ ./fossil version -v
 This is fossil version 1.26 [5d74ce03da] 2013-07-17 12:56:17 UTC
 Compiled on Jul 17 2013 21:46:29 using gcc-4.8.1 (32-bit)
 SQLite 3.8.0 2013-07-17 11:54:47 64bf8148b8
 zlib 1.2.3


 $ gdb fossil core
 Python Exception type 'exceptions.ImportError' No module named gdb:

 warning:
 Could not load the Python gdb module from `/opt/gdb7.6/share/gdb/python'.
 Limited Python support is available from the _gdb module.
 Suggest passing --data-directory=/path/to/gdb/data-directory.

 GNU gdb (GDB) 7.6
 Copyright (C) 2013 Free Software Foundation, Inc.
 License GPLv3+: GNU GPL version 3 or later
 http://gnu.org/licenses/gpl.html
 This is free software: you are free to change and redistribute it.
 There is NO WARRANTY, to the extent permitted by law.  Type show copying
 and show warranty for details.
 This GDB was configured as sparc-sun-solaris2.10.
 For bug reporting instructions, please see:
 http://www.gnu.org/software/gdb/bugs/...
 Reading symbols from /export/home/erb/tmp/t2/fossil...done.
 [New LWP 1]
 [Thread debugging using libthread_db enabled]
 [New Thread 1 (LWP 1)]
 Core was generated by `./fossil new t.fossil'.
 Program terminated with signal 10, Bus error.
 #0  whereLoopAddAll (pBuilder=0xffbff280) at src/sqlite3.c:109401
 109401  pNew-maskSelf = getMask(pWInfo-sMaskSet, pItem-iCursor);
 (gdb) list
 109396/* Loop over the tables in the join, from left to right */
 109397pNew = pBuilder-pNew;
 109398whereLoopInit(pNew);
 109399for(iTab=0, pItem=pTabList-a; iTabnTabList; iTab++, pItem++){
 109400  pNew-iTab = iTab;
 109401  pNew-maskSelf = getMask(pWInfo-sMaskSet, pItem-iCursor);
 109402  if( ((pItem-jointype|priorJoinType)  (JT_LEFT|JT_CROSS))!=0
 ){
 109403mExtra = mPrior;
 109404  }
 109405  priorJoinType = pItem-jointype;
 (gdb) q

 The error does not occur if fossil is built with -m64.

I guess that's one fix then -- what's the output of bt full in gdb?


 The error occurs using both the Solaris 10 provided gcc 3.4.3 and a
 locally built gcc 4.8.1.

 The error does not occur when using the Solaris Studio C compiler.

 --
 Edward Berner

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



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] By week-of-year statistics

2013-07-17 Thread B Harder

On Jul 17, 2013 12:58 AM, Stephan Beal sgb...@googlemail.com wrote:


 On Wed, Jul 17, 2013 at 12:35 AM, B Harder brad.har...@gmail.com wrote:

 Of top of head, reflexive position is that week numbers are running in
wrong order, but if it's reversed, latest would be at bottom of page.


 i sorted them DESC because i _suspect_ the most common use case will be
checking the current week. That's pure speculation, though, and i'm not
emotionally attached to the current (reverse) sorting.


 That made me wonder though, what of vertical bars vs. horizontal?

 Do you mean run the week numbers horizontally and count bars vertically?

Yes. If the width of the bars was more narrow, obviously more could fit, or
alternatively, instead of bars, perhaps a line graph, showing the general
shape.

I'm just throwing out unedited ideas ;)

What you've got is already cool, so take these ideas FWTW.

 When the week has 53 years that list gets really wide. When i had the
week list as part of the byyear view it was wrapping almost twice for most
years in the main fossil repo.

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] By week-of-year statistics

2013-07-16 Thread B Harder

Very cool, Stephan!
On Jul 16, 2013 1:30 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jul 16, 2013 at 6:49 PM, Matt Welland estifo...@gmail.com wrote:

 This looks cool. Will this data be available via the json interface?
 Being able to aggregate the stats over a lot of different fossils would be
 useful to some of us.


 New version:

 http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report

 then select the By week link, or just click this:


 http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek

 @Richard: as i recall, that's a report you specifically asked for?

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] By week-of-year statistics

2013-07-16 Thread B Harder

Of top of head, reflexive position is that week numbers are running in
wrong order, but if it's reversed, latest would be at bottom of page. That
made me wonder though, what of vertical bars vs. horizontal?

Just tossing ideas...
On Jul 16, 2013 1:50 PM, Stephan Beal sgb...@googlemail.com wrote:

 On Tue, Jul 16, 2013 at 5:57 PM, Stephan Beal sgb...@googlemail.comwrote:

 b) If someone with a better eye for design (that'd be just about anyone!)
 can suggest a less ugly/cramped presentation for how the week numbers are
 listed (see the first link above), i'd likewise be much obliged.


 Ignore that - that view was scrapped and replaced with a separate page:


 http://fossil.wanderinghorse.net/repos/cwal/index.cgi/stats_report?view=byweek

 @Brad/Matt: improvement suggestions are welcomed.

 --
 - 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Alias for first initial empty checkin?

Is there a:

$ fossil co initial_ci

Command/workalike available, or am I left to:

$ fossil timel -n   | tail
[copy SHA1]
$ fossil co [paste SHA1]

?

-bch

-- 
Brad Harder
Method Logic Digital Consulting
http://twitter.com/bcharder
___
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] Alias for first initial empty checkin?

On 7/15/13, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Jul 16, 2013 at 12:21 AM, B Harder brad.har...@gmail.com wrote:

 Is there a:

 $ fossil co initial_ci

 Command/workalike available, or am I left to:

 $ fossil timel -n   | tail
 [copy SHA1]
 $ fossil co [paste SHA1]


 There is a way to do it but you have to know the timeframe when the repo
 was started, e.g.:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00'
 === 2007-07-21 ===
 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags:
 trunk)
 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk)


I'm using this to make (eg) vendor branches that I don't want to
remain pure (ie: not related to history of whatever current branch
I'm on). Do other people do this? Is there a call for giving the
initial commit a non-sticky ci0 tag or such?

-bch



 interestingly, the above fails if i enter 14:10:00 as the time, though the
 first commit happened 1 second before that, but let's just call that a rare
 corner case and ignore it ;).

 (No, i didn't know the time of the first commit - i had to go search for it
 ;)

 So we end up with this:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' |
 tail -1 | cut -d'[' -f2 | cut -d']' -f1
 a28c83647d

 or:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00' |
 tail -1 | cut -d' ' -f2
 [a28c83647d]

 depending on what format you want.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Alias for first initial empty checkin?

** s/don't want to remain pure/want to remain pure/.

On 7/15/13, B Harder brad.har...@gmail.com wrote:
 On 7/15/13, Stephan Beal sgb...@googlemail.com wrote:
 On Tue, Jul 16, 2013 at 12:21 AM, B Harder brad.har...@gmail.com wrote:

 Is there a:

 $ fossil co initial_ci

 Command/workalike available, or am I left to:

 $ fossil timel -n   | tail
 [copy SHA1]
 $ fossil co [paste SHA1]


 There is a way to do it but you have to know the timeframe when the repo
 was started, e.g.:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00'
 === 2007-07-21 ===
 14:10:57 [dbda8d6ce9] Initial check-in of m1 sources. (user: drh tags:
 trunk)
 14:09:59 [a28c83647d] initial empty baseline (user: drh tags: trunk)


 I'm using this to make (eg) vendor branches that I don't want to
 remain pure (ie: not related to history of whatever current branch
 I'm on). Do other people do this? Is there a call for giving the
 initial commit a non-sticky ci0 tag or such?

 -bch



 interestingly, the above fails if i enter 14:10:00 as the time, though
 the
 first commit happened 1 second before that, but let's just call that a
 rare
 corner case and ignore it ;).

 (No, i didn't know the time of the first commit - i had to go search for
 it
 ;)

 So we end up with this:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00'
 |
 tail -1 | cut -d'[' -f2 | cut -d']' -f1
 a28c83647d

 or:

 stephan@tiny:~/cvs/fossil/fossil$ f timeline before '2007-07-21 14:11:00'
 |
 tail -1 | cut -d' ' -f2
 [a28c83647d]

 depending on what format you want.

 --
 - stephan beal
 http://wanderinghorse.net/home/stephan/
 http://gplus.to/sgbeal



 --
 Brad Harder
 Method Logic Digital Consulting
 http://www.methodlogic.net/
 http://twitter.com/bcharder



-- 
Brad Harder
Method Logic Digital Consulting
http://www.methodlogic.net/
http://twitter.com/bcharder
___
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] Alias for first initial empty checkin?