On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com wrote:
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:
hi,
I have stumbled over the following observation when performing these
action within a checkout of of `fossil' itself:
fossil timeline -v -n 10 | grep 5731 ## -- no hit
fossil diff -r 5731 ## lots of output (related to which revision???)
hopefully not a stupid question: what's going
On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff veedeeh...@googlemail.com
wrote:
hopefully not a stupid question: what's going on here? can someone confirm
this? there is no checkin with a SHA1 hash starts with 5731 (or contain it)
it seems.
An undocumented feature: artifact symbols which
On Wed, Aug 21, 2013 at 12:58 PM, Stephan Beal sgb...@googlemail.comwrote:
On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff
veedeeh...@googlemail.com wrote:
hopefully not a stupid question: what's going on here? can someone
confirm this? there is no checkin with a SHA1 hash starts with
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 12:53 PM, j. van den hoff
veedeeh...@googlemail.com
wrote:
hopefully not a stupid question: what's going on here? can someone
confirm
this? there is no checkin with a SHA1 hash starts
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to add it to the manpages?
Intentional - see the comment line at the start of that
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.com wrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to
I actually wanted to simply post a bug report to the ticket system, but
it's telling me it will be deleted unless I go through the hoops of the
mailing list registration process. (Uh?!? Why then technically enable
anonymous ticket submissions in the 1st place?) Oh well...
My findings:
In a
On Wed, Aug 21, 2013 at 7:48 AM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 7:25 AM, Stephan Beal sgb...@googlemail.comwrote:
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.com wrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal
On Wed, Aug 21, 2013 at 7:49 AM, fossilscm@xoxy.net wrote:
I actually wanted to simply post a bug report to the ticket system, but
it's telling me it will be deleted unless I go through the hoops of the
mailing list registration process. (Uh?!? Why then technically enable
anonymous ticket
Yes, I did. (That was my 1st thought, too.) Sorry, forgot to mention it.
On Wed, Aug 21, 2013 at 1:51 PM, Richard Hipp - d...@sqlite.org
fossilscm.zoc.5877ad8d94.drh#sqlite@ob.0sg.net wrote:
On Wed, Aug 21, 2013 at 7:49 AM, fossilscm@xoxy.net wrote:
I actually wanted to simply post
On Wed, Aug 21, 2013 at 1:48 PM, Richard Hipp d...@sqlite.org wrote:
In fact, I thought that was the way it worked, though I haven't looked at
the code lately and I might have missed something.
That is how it works - it's a last-ditch effort before returning 0.
Adding an rid: prefix to it is
2013/8/21 fossilscm@xoxy.net:
In a directory that contains several .* files and subfolders, several *.css
files and a single .php file, the following work fine with version 1.24, but
only output a usage info with 1.25+ (fossil: Usage: fossil set ?PROPERTY?
?VALUE?):
This is already fixed
On Tue, Aug 20, 2013 at 09:28:00PM +0200, Stephan Beal wrote:
On Tue, Aug 20, 2013 at 9:03 PM, John Long codeb...@inbox.lv wrote:
My understanding is you already compute checksums on commits.
At a lot of places. Blob content is referenced by its content SHA1, so
any change there
2013/8/21 Jan Nijtmans jan.nijtm...@gmail.com:
2013/8/21 fossilscm@xoxy.net:
In a directory that contains several .* files and subfolders, several *.css
files and a single .php file, the following work fine with version 1.24, but
only output a usage info with 1.25+ (fossil: Usage: fossil
On Wed, Aug 21, 2013 at 1:49 PM, fossilscm@xoxy.net wrote:
I actually wanted to simply post a bug report to the ticket system, but
it's telling me it will be deleted unless I go through the hoops of the
mailing list registration process. (Uh?!? Why then technically enable
anonymous ticket
@Jan: Nope it's not fixed in 1.26.
In fact I noticed it with 1.26, then regressed to 1.25 to check if the bug
was there, then to 1.24. (I intentionally used the plus sign when referring
to 1.25+)
On Wed, Aug 21, 2013 at 1:56 PM, Jan Nijtmans - jan.nijtm...@gmail.com
Just re-confirmed:
$ fossil set ignore-glob *.css
Usage: fossil set ?PROPERTY? ?VALUE?
$ fossil ver
This is fossil version 1.26 [c9cb6e7293] 2013-06-18 21:09:23 UTC
On Wed, Aug 21, 2013 at 2:10 PM, Zoran Isailovski fossilscm@xoxy.netwrote:
@Jan: Nope it's not fixed in 1.26.
In fact
Thanks for the advice. However, I had already tried the single quote thing
earlier, but I dismissed it, because AFAIK single quotes are not handled as
string delimiters in the Windows shell, and:
$ fossil set ignore-glob *.xxx
$ fossil set ignore-glob
ignore-glob (local) *.xxx
But:
On Wed, Aug 21, 2013 at 1:58 PM, John Long codeb...@inbox.lv wrote:
If I understood what you wrote, the checkin manifest is some kind of meta
data about the commit
Correct. It tells us what blobs (stored separately) belong to the commit
and hold some metadata for it (comment text, user
@
Stephan Beal: So fossil is refusing to eat it's own dog food - or rather one
of its more unique assets: The integrated wiki and ticket system? :-)
But since I must accept the culture of the place I'm visiting, perhaps you
can help out a novice mailman list fellow: Is there any way to only
On Wed, Aug 21, 2013 at 2:31 PM, fossilscm@xoxy.net wrote:
@
Stephan Beal: So fossil is refusing to eat it's own dog food - or rather one
of its more unique assets: The integrated wiki and ticket system? :-)
This problem is Windows-specific. In every Unix shell *.css, '*.css will
be
It's a problem with the way MinGW parses and passes the command line. When
main is called in fossil, the arguments are already expanded. As for the
fix, I am not sure yet.
On Wed, Aug 21, 2013 at 2:36 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 2:31 PM,
On Wed, Aug 21, 2013 at 8:31 AM, fossilscm@xoxy.net wrote:
@
Stephan Beal: So fossil is refusing to eat it's own dog food - or rather one
of its more unique assets: The integrated wiki and ticket system? :-)
We find that anonymously contributed tickets and wiki are generally of low
On Sun, Aug 18, 2013 at 05:20:35PM +0200, Michai Ramakers wrote:
1) on host S: clone project from host S (http://S/my_repo)
2) on host C: clone project from host S (http://S/my_repo)
3) on host C: do some work, and commit changes
4) on host S, 'fossil up'
5) on host S: 'fossil timeline'
Following change fixes it for met with MinGW 32 bit on windows 7.
$ fossil diff src/main.c
argc in wmain 3
--- src/main.c
+++ src/main.c
@@ -522,11 +522,13 @@
*/
#if defined(_WIN32) !defined(BROKEN_MINGW_CMDLINE)
int _dowildcard = -1; /* This turns on command-line globbing in MinGW-w64
*/
On Wed, Aug 21, 2013 at 08:37:43AM +0200, Michai Ramakers wrote:
On 21 August 2013 05:25, Donny Ward donnyjw...@gmail.com wrote:
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
On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.com wrote:
I did not test this with the 64bit version of MinGW. Using an unquoted *
in this case still works as expected.
as expected means, i assume: resolves to a list of all files matching *
in the current directory? (That's
Yes, for example fossil add * will still do the right thing.
On Wed, Aug 21, 2013 at 2:51 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 2:48 PM, Mark Janssen mpc.jans...@gmail.comwrote:
I did not test this with the 64bit version of MinGW. Using an unquoted *
in this
Sorry for spamming, but with the change it works within msys, but it fails
on the windows command line. Seems like a bit of a Catch 22 caused by the
different idea windows and unix have about how to pass arguments.
On Wed, Aug 21, 2013 at 2:52 PM, Mark Janssen mpc.jans...@gmail.com wrote:
On Wed, Aug 21, 2013 at 8:49 AM, Chad Perrin c...@apotheon.net wrote:
That sounds familiar. For the record, let me say I never (ever) make
branches; all work here is done on trunk.
In the repository where a fellow developer and I have seen this problem,
there have been no intentional
2013/8/21 Mark Janssen mpc.jans...@gmail.com:
Sorry for spamming, but with the change it works within msys, but it fails
on the windows command line. Seems like a bit of a Catch 22 caused by the
different idea windows and unix have about how to pass arguments.
See:
@Stephen:
But since I must accept the culture of the place I'm visiting, perhaps you
can help out a novice mailman list fellow: Is there any way to only receive
emails from threads I am participating in?
i haven't used Windows (outside of customer sites and an occasional game of
Empire at
One thing to add here, is that when this happened for us, I had two
different clones, one in a VM, and one on my workstation, and both of these
couldn't see the 'faulty' commit until I re-cloned the repo (on both).
So it seems to be a feature of the commit (or the copy that hits the
server)
Uhm, perhaps a naive outsider question, but how came the issue wasn't
there before 1.25, if it's the differences in how the different shells
process CLI arguments? Did the shells not remain the same in between?
On Wed, Aug 21, 2013 at 3:02 PM, Mark Janssen - mpc.jans...@gmail.com
On Wed, 21 Aug 2013 13:25:50 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 1:22 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 12:58:35 +0200, Stephan Beal sgb...@googlemail.com
wrote:0.
intentionally undocumented or did nobody manage to
On Wed, Aug 21, 2013 at 9:23 AM, fossilscm@xoxy.net wrote:
Uhm, perhaps a naive outsider question, but how came the issue wasn't
there before 1.25, if it's the differences in how the different shells
process CLI arguments? Did the shells not remain the same in between?
My guess is that
On Wed, Aug 21, 2013 at 3:18 PM, fossilscm@xoxy.net wrote:
Uh? My question was about the mailman mailing list?!? How is that related
to Windows?
Because your top-post came immediately after such a question i took it out
of context.
In any other respect, I take your response as rather...
On Wed, Aug 21, 2013 at 1:50 PM, Richard Hipp d...@sqlite.org wrote:
Furthermore, this feature is for debugging use only and should not get in
the way of end users. Perhaps it should be changed such that the record ID
is only used if the input begins with rid:?
Just checked in:
unintentionally replied only to stephan, but this should stay on th list,
I'd say, so:
On Wed, 21 Aug 2013 16:08:16 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 3:25 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
philosophical issues aside:
does that mean
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
with due respect, that's too dogmatic for my taste. and it's also a
question what you decide to include
Domagtic, it is. It is a fact of software development, in particular
long-lived software, that once an
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
Joerg's original proposal (in a previous thread) was to support
_local_
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
This topic has been beaten to death by brains much larger than mine.
2013/8/19 Stephan Beal sgb...@googlemail.com:
As long as the artifact types are syntactically unambiguous, meaning it's
always possible to determine their type based on their card letters (letters
only, ignoring the card parameters), i'm happy :). Any ambiguity would
potentially open up a big
last mail in these matters since it is in danger of deteriorating into
just another flame.
On Wed, 21 Aug 2013 16:36:58 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 4:26 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
with due respect, that's too dogmatic
On Wed, Aug 21, 2013 at 5:13 PM, Jan Nijtmans jan.nijtm...@gmail.comwrote:
I'm looking at the algorithm in fossil now which determines the
type. Most types are easy to distinguish because they have unique
cards which only occur in that type. The only difficult types are
Control artifacts and
On Wed, Aug 21, 2013 at 5:10 PM, Stephan Beal sgb...@googlemail.com wrote:
such problems if they cannot be reproduced easily. i could see it being
halfway reliable for diffs, but not commits, because any change to the
filesystem or repo can change the list of files used by the commit command.
In TCC (a CMD replacement for windows), I use the following where %_unixtime is
a variable representing the current time.
echo insert into config (name,value,mtime) values
(timeline-utc,0,%_unixtime); | fossil sql
From: fossil-users-boun...@lists.fossil-scm.org
On Wed, Aug 21, 2013 at 5:09 PM, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential numbers.
On Wed, Aug 21, 2013 at 11:26 AM, Mark Janssen mpc.jans...@gmail.comwrote:
One reason which would make my life easier is when dealing with tickets,
it is much easier to discuss bug 12 (in blessed repo X) instead of ticket
uuid [some 8+ digit number]. When I work with tickets on github I know
On Wed, Aug 21, 2013 at 5:26 PM, Mark Janssen mpc.jans...@gmail.com wrote:
One reason which would make my life easier is when dealing with tickets,
it is much easier to discuss bug 12 (in blessed repo X) instead of ticket
uuid [some 8+ digit number]. When I work with tickets on github I know
For most of the use cases discussed here I think we don't need repository
local unique numbers a la mercurial. As far as I can see a more flexible
VERSION [1] format (although the git way is probably overkill) seems to be
enough. It would be useful for example to be able to say:
fossil diff -r -2
Regarding stable numbered tags. How about a script or added feature that
scans the timeline and tags every node in a systematic way similar to what
people might expect from Subversion or similar tools?
v1.1 - v1.2 - v1.3
\.- v1.1.1
If the script worked incrementally and was run centrally
On Wed, 21 Aug 2013 17:09:52 +0200, Richard Hipp d...@sqlite.org wrote:
On Wed, Aug 21, 2013 at 10:52 AM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential
numbers.
On Wed, 21 Aug 2013 17:10:59 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 4:52 PM, Marc Simpson m...@0branch.com wrote:
On Wed, Aug 21, 2013 at 3:36 PM, Stephan Beal sgb...@googlemail.com
wrote:
DVCSs cannot, by their very nature, portably support sequential
On Wed, Aug 21, 2013 at 5:37 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
thanks for this clarification. so, while you don't share my view that the
sequential revnums (yes: exactly the same thing as in mercurial) are a good
thing, I still do (from some years of usage of mercurial). I've
On Wed, Aug 21, 2013 at 5:43 PM, Stephan Beal sgb...@googlemail.com wrote:
Side-note...
the library interface will allow clients to add this sort of supplemental
metadata/functionality, and will eventually provide enough
Side-note #2/shameless plug: the library effort is coming along nicely
I'll reply to this mail again, since it is essentially the only one
exactly addressing my point:
-- I agree that any non-local use of revnums is doomed to failure (with
checkins tickets or whatever).
-- we don't need some new `svn' like naming scheme of revisions instead of
the hashes
Hi, all,
The current list of upvoted names (no, Brad, urvogel's not one of them ;)
for the on-going/up-coming library API includes (in my personal order of
preference, but i'm not emotionally attached to these):
- libfossil-scm and fossil(3)
- libfossil
- liblissof (fossil, backwards, because
On Wed, Aug 21, 2013 at 8:37 AM, Matt Welland estifo...@gmail.com wrote:
Regarding stable numbered tags. How about a script or added feature that
scans the timeline and tags every node in a systematic way similar to what
people might expect from Subversion or similar tools?
v1.1 - v1.2 -
Ooh, I love bikeshedding.
What about libfree as a portmanteau of lib, fossil, and three? I guess
that crosses the line into humor a bit.
More seriously though, fossil(3) is my favorite, but it does make it sound
like it's an official part of the fossil project and actually implies, at
least to
To make this less of an academic discussion and to just be able to play
around with it,
http://mpcjanssen.nl/fossil/fossil/vdiff?from=root:revlistto=r:5746sbs=1 has
an implementation of having repository local rev numbers for commits only.
After updating fossil you'll need to do a fossil rebuild
On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.com wrote:
Currently the revision numbers are reflecting the fossil rebuild algorithm
so they count down from leaves which is a bit odd, but that can probably be
improved.
Coincidentally, this block _might_ affect you in a
On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher
themba.fletc...@gmail.comwrote:
What about libfree as a portmanteau of lib, fossil, and three? I guess
that crosses the line into humor a bit.
And sounds very GNU :/.
More seriously though, fossil(3) is my favorite, but it does make it sound
On Wed, Aug 21, 2013 at 7:36 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 7:31 PM, Mark Janssen mpc.jans...@gmail.comwrote:
Currently the revision numbers are reflecting the fossil rebuild
algorithm so they count down from leaves which is a bit odd, but that can
On Wed, Aug 21, 2013 at 7:38 PM, Stephan Beal sgb...@googlemail.com wrote:
On Wed, Aug 21, 2013 at 7:30 PM, Themba Fletcher
themba.fletc...@gmail.com wrote:
What about libfree as a portmanteau of lib, fossil, and three? I guess
that crosses the line into humor a bit.
And sounds very GNU
@Stephan Beal: Thanks man. And I'll admit I might have been a tick too
sensible about it. :-)
I'm very well aware that Windows is a bloated piece of ... code full of
deficiencies. But if something used to work well up to a certain version
(I'm using fossil since years, could have been 0.something
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
On Wed, Aug 21, 2013 at 7:43 PM, fossilscm@xoxy.net wrote:
@Stephan Beal: Thanks man. And I'll admit I might have been a tick too
sensible about it. :-)
...Anyway, I did not want to go in too deep about the whole matter. I
thought you guys would want feedback on issues because it is a
@Richard:
My guess is that the one of the prebuild binaries was compiled with MinGW
and the other with MSVC.
Just to provide some information so you can verify your guess: I've been
using fossil since years now, (on XP, Vista, and now Win7,) and I updated
regularly (though I can't be sure I
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
To make this less of an academic discussion and to just be able to play
very good point (despite being myself in academia ...) and thanks a lot
for sharing this.
around with it,
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
To make this less of an academic discussion and to just be able to play
very good point (despite being myself in academia ...) and
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.comwrote:
The fossil rebuild logic uses a two pass algorithm. I am not quite sure
why this is necessary, it could have something to do with delta manifests.
At http://mpcjanssen.nl/fossil/fossil/timeline?r=revlist I have changed
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
To make this less of an academic discussion and to
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen
mpc.jans...@gmail.comwrote:
The fossil rebuild logic uses a two pass algorithm. I am not quite sure
why this is necessary, it could have something to do with delta
On Wed, Aug 21, 2013 at 11:22 PM, j. van den hoff veedeeh...@googlemail.com
wrote:
understood. what I do not get is (apart from that's it probably not part
of the current machinery) why it
would be complicated (for the people in the know) to just log the checkins
and count them while they
On 21 Aug 2013 23:22, j. van den hoff veedeeh...@googlemail.com wrote:
On Wed, 21 Aug 2013 23:07:36 +0200, Mark Janssen mpc.jans...@gmail.com
wrote:
On Wed, Aug 21, 2013 at 9:27 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 19:31:17 +0200, Mark Janssen
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
On Wed, Aug 21, 2013 at 2:29 PM, j. van den hoff
veedeeh...@googlemail.comwrote:
On Wed, 21 Aug 2013 23:19:46 +0200, Stephan Beal sgb...@googlemail.com
wrote:
On Wed, Aug 21, 2013 at 11:07 PM, Mark Janssen mpc.jans...@gmail.com
wrote:
The fossil rebuild logic uses a two pass algorithm. I
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
On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote:
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
On Wed, Aug 21, 2013 at 08:05:58PM -0600, Chad Perrin wrote:
On Wed, Aug 21, 2013 at 06:03:50PM -0700, B Harder wrote:
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/
Hi all -
I've got a lot of fossil repositories, and for backup purposes I encrypt
and upload them to cloud storage.
The backup process runs every night, but I don't want to upload repos
which haven't changed. My initial thought was that I could just do an
sha1 hash of the repo. But it turns
84 matches
Mail list logo
