On 2/25/15, Marcus Lam wrote:
> Noted.
>
> On the "Fossil Concepts" page, under section "4.2 Manual-Merge Workflow", at
> step 8 there is a typo of "use use".
>
Thanks. Should be fixed now.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing l
Noted.
On the "Fossil Concepts" page, under section "4.2 Manual-Merge Workflow", at
step 8 there is a typo of "use use".
Regards
Marcus Lam
> Date: Wed, 25 Feb 2015 00:12:36 -0500
> From: d...@sqlite.org
> To: fossil-users@lists.fossil-scm.org
> Subject: Re: [fossil-users] Newbie question - ho
On 2/25/15, Marcus Lam wrote:
> Hi,
>
> New to Fossil. Found a typo while reading the online Fossil Concepts page.
> Want to raise a ticket for that but could not locate instruction for doing
> so. Any pointer?
Email to this mailing list is the fastest way to get something fixed.
--
D. Richar
Hi,
New to Fossil. Found a typo while reading the online Fossil Concepts page.
Want to raise a ticket for that but could not locate instruction for doing so.
Any pointer?
Regards
Marcus Lam
___
fossil-users
On Wed, Feb 25, 2015 at 3:25 AM, Martin Gagnon wrote:
> On Wed, Feb 25, 2015 at 02:47:24AM +0100, Stephan Beal wrote:
> >On Wed, Feb 25, 2015 at 2:32 AM, jungle Boogie <
> jungleboog...@gmail.com>
> >wrote:
> >
> > Are these two supposed to match? should the compression ratio be the
On Wed, Feb 25, 2015 at 02:47:24AM +0100, Stephan Beal wrote:
>On Wed, Feb 25, 2015 at 2:32 AM, jungle Boogie
>wrote:
>
> Are these two supposed to match? should the compression ratio be the
> same for my clone vs, website report?
>
>They "should" be identical - the CLI com
Hi Stephan,
On Feb 24, 2015 5:47 PM, "Stephan Beal" wrote:
>
> On Wed, Feb 25, 2015 at 2:32 AM, jungle Boogie
wrote:
>>
>> Are these two supposed to match? should the compression ratio be the
>> same for my clone vs, website report?
>
>
> They "should" be identical - the CLI command was initially
On Wed, Feb 25, 2015 at 2:32 AM, jungle Boogie
wrote:
> Are these two supposed to match? should the compression ratio be the
> same for my clone vs, website report?
>
They "should" be identical - the CLI command was initially derived from the
/stats page. It is possible that they have deviated s
Hello All,
Se we have this command:
https://www.fossil-scm.org/fossil/help?cmd=dbstat
And this for web UI:
https://www.fossil-scm.org/fossil/help?cmd=/stat
Fossil repo stats: https://www.fossil-scm.org/fossil/stat
Are these two supposed to match? should the compression ratio be the
same for my
On 24 February 2015 at 16:50, Ron W wrote:
> On Tue, Feb 24, 2015 at 7:01 PM, Stephan Beal wrote:
>>
>> On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp wrote:
>>>
>>> So it seems like having dates on the download would be more meaningful
>>> than having a made-up version number. No? With a date,
On 2/24/15, Ron W wrote:
> [Managers] associate dates with deadlines, so version numbers remove
> a source of panic.
Fair enough. I'll migrate from dates to version numbers in the next release.
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users maili
On Tue, Feb 24, 2015 at 7:01 PM, Stephan Beal wrote:
> On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp wrote:
>
>> So it seems like having dates on the download would be more meaningful
>> than having a made-up version number. No? With a date, at least you
>> know about how old the code is. Wha
On Tue, Feb 24, 2015 at 9:11 PM, Richard Hipp wrote:
> So it seems like having dates on the download would be more meaningful
> than having a made-up version number. No? With a date, at least you
> know about how old the code is. What information does a made-up
> version number provide? How i
On Tue, Feb 24, 2015 at 3:59 PM, jungle Boogie wrote:
> Hi Joe,
> How have you been updating packages in the past?
>
> All releases are like this:
> 20150223162734
> 20150119112900
> 20140612172556
> 20140127173344
> 2013094349
I just used those as they were without issue. See any of the re
On Tue, Feb 24, 2015 at 5:16 PM, Richard Hipp wrote:
> It's going to be more complicated than that. The people who want
> ...
> Since this is a major change, I propose that it be deferred until
> Fossil 2.0 (which will likely be the next release).
>
Honestly, it doesn't matter to me. Mr robotan
On 2/24/15, Andy Goth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> On 2/24/2015 3:21 PM, Ron W wrote:
>> Took a quick look at Fossil commits tagged "release", I see tags
>> like "version-1.31", "version-1.30", etc. I also see references to
>> SQLite versions in the form x.y.z as op
On Tue, Feb 24, 2015 at 4:47 PM, Andy Goth wrote:
> So just grab the file at this URL:
>
>
> https://www.fossil-scm.org/fossil/tarball/fossil-1.31.tar.gz?uuid=version-1.31
>
> and be happy. The file will have the name you want.
>
> Or replace "1.31" with whichever tagged release you desire.
>
>
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 2/24/2015 3:21 PM, Ron W wrote:
> Took a quick look at Fossil commits tagged "release", I see tags
> like "version-1.31", "version-1.30", etc. I also see references to
> SQLite versions in the form x.y.z as opposed to a date string.
>
> Seems like
Hi Ron,
On 24 February 2015 at 13:24, Ron W wrote:
> BTW, would be useful to have an entry in the search type pull-down for tags
> (there were a lot of occurrences of "release" in the comments).
Although not exposed as a menu option there is this link:
http://fossil-scm.org/index.html/taglist
Ye
you're right, my mistake -- "closed" is what I meant, but didn't
describe properly. :P
On 2/24/15, Jan Nijtmans wrote:
> 2015-02-24 20:37 GMT+01:00 bch :
>> Tags are symbolic names that may or may not be propagate -- a branch
>> name is an example of a propagating tag, and a non-propagating tag m
On Tue, Feb 24, 2015 at 4:21 PM, Ron W wrote:
>
> Took a quick look at Fossil commits tagged "release", I see tags like
> "version-1.31", "version-1.30", etc. I also see references to SQLite
> versions in the form x.y.z as opposed to a date string.
>
BTW, would be useful to have an entry in the s
On Tue, Feb 24, 2015 at 3:59 PM, jungle Boogie
wrote:
>
> How have you been updating packages in the past?
>
> All releases are like this:
> 20150223162734
> 20150119112900
> 20140612172556
> 20140127173344
> 2013094349
Took a quick look at Fossil commits tagged "release", I see tags like
"v
Hi Joe,
On 24 February 2015 at 12:38, Joe Prostko wrote:
> I think this is mostly handy for packagers, where it's easier to write
> a packaging script knowing the downloaded file will be
> somepieceofsoftware-1.2.3.tar.gz, which then extracts out to
> somepieceofsoftware-1.2.3. It is mostly a mat
Am Tue, 24 Feb 2015 15:38:37 -0500
schrieb Joe Prostko :
> On Tue, Feb 24, 2015 at 3:11 PM, Richard Hipp wrote:
> That said, if the version number isn't important,
> why didn't you call the latest release Fossil 20150223162734 instead
> of Fossil 1.31?
That is a good question!
__
On Tue, Feb 24, 2015 at 3:11 PM, Richard Hipp wrote:
> On 2/24/15, robotanarchy wrote:
>> I'd replace the underscore with a dot, so it becomes
>>
>> fossil-1.31.tar.gz
>>
>> ..but other than that, that's my point.
>>
>> Can you guys do that?
>>
>
> We can call things whatever we want. It's
On 2/24/15, robotanarchy wrote:
> Am Tue, 24 Feb 2015 12:04:06 -0500
> schrieb Ron W :
>
>
>> But, in any case, Mr robotanarchy seems to be requesting that the
>> official release tar file be created with, for example:
>>
>> fossil tarball version-1.31 fossil-src-1_31.tar.gz --name
>> fossi
Seen with Fossil 1.29, and reproduced
with b0febccc4e1cf5c6763e3aa088b1ea788d255e47 (2015-02-24 06:03:54).
Summary:
I created a new branch, and in the new branch:
- Committed a rename of file A to B.
- Committed an add of a new file A.
- Committed changes to files A and B.
Then I merged the new
Am Tue, 24 Feb 2015 12:04:06 -0500
schrieb Ron W :
> But, in any case, Mr robotanarchy seems to be requesting that the
> official release tar file be created with, for example:
>
> fossil tarball version-1.31 fossil-src-1_31.tar.gz --name
> fossil-src-1_31
>
> to make it easier to identi
2015-02-24 20:37 GMT+01:00 bch :
> Tags are symbolic names that may or may not be propagate -- a branch
> name is an example of a propagating tag, and a non-propagating tag may
> be (for example) a tag that marks a specific commit as a "release"
> (see: http://fossil-scm.org/index.html/timeline?r=v
Tags are symbolic names that may or may not be propagate -- a branch
name is an example of a propagating tag, and a non-propagating tag may
be (for example) a tag that marks a specific commit as a "release"
(see: http://fossil-scm.org/index.html/timeline?r=version-1.30) -- if
a branch is marked as
On Tue, Feb 24, 2015 at 12:02 PM, Richard Hipp wrote:
> On 2/24/15, Andy Goth wrote:
>> Unlike previous releases, the unpacked directory name does not contain the
>> seconds. This means the directory and archive filenames don't match, which
>> is a problem for the SlackBuild script.
>>
>> Are t
On Tue, Feb 24, 2015 at 11:27 AM, Baptiste Daroussin <
baptiste.darous...@gmail.com> wrote:
> 2015-02-24 15:30 GMT+01:00 Richard Hipp :
> > On 2/24/15, robotanarchy wrote:
> >> When downloading file [1], you'll get an archive that has a different
> >> file name than the included folder. The folde
Hi,
What does selecting "Tags" in Timeline actually do? I was expecting to see
the list of non-propagating tags but I don't understand how I could use the
output I see.
Also, what does unhide actually do? Why do I need to explicitly click
"unhide" to see any output on this page:
https://www.fossil
On 2/24/15, Andy Goth wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> $ tar tzf fossil-src-20150223162734.tar.gz | head -1
> fossil-src-201502231627/
>
> Unlike previous releases, the unpacked directory name does not contain the
> seconds. This means the directory and archive filenam
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
$ tar tzf fossil-src-20150223162734.tar.gz | head -1
fossil-src-201502231627/
Unlike previous releases, the unpacked directory name does not contain the
seconds. This means the directory and archive filenames don't match, which is
a problem for the
2015-02-24 15:30 GMT+01:00 Richard Hipp :
> On 2/24/15, robotanarchy wrote:
>> Hello Fossil developers,
>>
>> I was building the fossil binary yesterday and I've noticed that the
>> names of the tarballs aren't very userfriendly.
>>
>> As I see it, there are two tarballs that one could use, one is
Ok, that Login-Group thing seems to be what I searched for. Thank you for
your patience.
Richard Hipp schrieb am Tue Feb 24 2015 at 17:17:23:
> On 2/24/15, Oliver Friedrich wrote:
> > Interesting thing, still the two demo repositoris repoA and repoB.
> > Both fired up with fossil ui repo[AB].fo
On 2/24/15, Oliver Friedrich wrote:
> Interesting thing, still the two demo repositoris repoA and repoB.
> Both fired up with fossil ui repo[AB].fossil, then using the web frontend
> to change password of the default user to "123". Then the repos will both
> have different hashes for the passwords
Interesting thing, still the two demo repositoris repoA and repoB.
Both fired up with fossil ui repo[AB].fossil, then using the web frontend
to change password of the default user to "123". Then the repos will both
have different hashes for the passwords. Seems the password hashes get
somehow salte
On Tue, Feb 24, 2015 at 5:01 PM, Richard Hipp wrote:
> On 2/24/15, Oliver Friedrich wrote:
> > I'd really appreciate having a static url to get the latest
> stable/testing
> > sources from.
>
>
> https://www.fossil-scm.org/fossil/tarball/fossil-src-stable.tar.gz?uuid=release
And for "testing",
On Tue, Feb 24, 2015 at 03:52:56PM +, Oliver Friedrich wrote:
> Just to throw my thought on this into the discussion.
>
>
> I'd really appreciate having a static url to get the latest stable/testing
> sources from.
>
> So to be able to download from https://www.fossil-scm.org/download/
>
On 2/24/15, Oliver Friedrich wrote:
>>
>> Just to throw my thought on this into the discussion.
>
>
> I'd really appreciate having a static url to get the latest stable/testing
> sources from.
https://www.fossil-scm.org/fossil/tarball/fossil-src-stable.tar.gz?uuid=release
>
> So to be able to do
>
> Just to throw my thought on this into the discussion.
I'd really appreciate having a static url to get the latest stable/testing
sources from.
So to be able to download from
https://www.fossil-scm.org/download/fossil-src-stable.tar.gz the latest
stable sources.
Maybe that even makes it poss
Maybe I missed something, but the help states fossil import overwrites by
default, doesn't it? Also there is nothing mentioned about that parameter
in the import command.
beowulf@PowerWolf:~$ fossil help config import
Usage: fossil configuration METHOD ... ?OPTIONS?
Where METHOD is one of: export
On 2/24/15, Oliver Friedrich wrote:
> So, got some time into things, it seems to me, that the fossil config
> import command does not work properly.
>
> My Testcase:
> beowulf@PowerWolf:~$ fossil init repoA.fossil
> project-id: c3c22922a11b4a6536af4c2506369f3926ae1d1f
> server-id: b7e6a9010387a9e
So, got some time into things, it seems to me, that the fossil config
import command does not work properly.
My Testcase:
beowulf@PowerWolf:~$ fossil init repoA.fossil
project-id: c3c22922a11b4a6536af4c2506369f3926ae1d1f
server-id: b7e6a9010387a9ea7d163c9f40c8a274192a9989
admin-user: user (initia
On Tue, Feb 24, 2015 at 3:55 PM, Svyatoslav Mishyn
wrote:
> BTW, the manual page is not installing by the command ```make install```
>
There isn't one to install.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the on
Hello,
Index: src/browse.c
==
--- /home/juef/fossil/e/fossil/src/browse.c~0 2015-02-24 16:31:46.677114589
+0200
+++ /home/juef/fossil/e/fossil/src/browse.c 2015-02-24 16:21:11.700411735
+0200
@@ -1035,7 +1035,7 @@
@ %z(hre
Am Tue, 24 Feb 2015 15:33:42 +0100
schrieb Stephan Beal :
> On Tue, Feb 24, 2015 at 3:30 PM, Richard Hipp wrote:
>
> > Providing a date on the filename seems (to me) a lot more useful
> > than a random SHA1 hash.
> >
>
> +1, if only because they retain their release order when sorted
> lexicall
On 2/24/15, robotanarchy wrote:
> Hello Fossil developers,
>
> I was building the fossil binary yesterday and I've noticed that the
> names of the tarballs aren't very userfriendly.
>
> As I see it, there are two tarballs that one could use, one is from the
> downloads page [1] and one is by using
On Tue, Feb 24, 2015 at 3:30 PM, Richard Hipp wrote:
> Providing a date on the filename seems (to me) a lot more useful than
> a random SHA1 hash.
>
+1, if only because they retain their release order when sorted lexically.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://g
Hello Fossil developers,
I was building the fossil binary yesterday and I've noticed that the
names of the tarballs aren't very userfriendly.
As I see it, there are two tarballs that one could use, one is from the
downloads page [1] and one is by using some strange SHA1 hash of the
release, as in
52 matches
Mail list logo
