Re: [fossil-users] features I'd like to have in fossil

[Ron W]

At the risk of wading in to a minefield, I have some thoughts.

On Fri, Oct 21, 2016 at 2:14 PM, 
wrote:
>
> From: Nikita Borodikhin 
> Date: Fri, 21 Oct 2016 16:02:33 +
>
> == combined log - history ananlysis ==
>
> The most unusual thing about Fossil is that it does not have "log" command.  
> [...]  In Fossil, there is no easy command line way to get the history of a 
> subtree.
>
>
Other than:
fossil finfo path/to/dir/*

I don't know what history of a subtree would be. Fossil tracks files, not
directories

I believe that most users are used to that universal log command and I
would be surprised if fossil's timeline/finfo duo is not _the_ most
thing people struggle with in the beginning of their relationship with
Fossil.
>
>
Never bothered me. I rarely use finfo, I suspect this may have been the
case in the early days of Fossil, with finfo being added as a separate
command, perhaps to avoid issues with the parsing of the existing timeline
command.

If someone were inclined enough to implement a new log command that could
show either commit history or file history, the constraints of the existing
timeline command could be avoided.


> == relative revisions - history analysis ==
>
> In Fossil there is no way to refer to a parent of a revision, with the 
> exception the parent of checked out revision.
>
>
Once in a while, being able to specify a revision relative to another would
be handy.

While git's ^ suffix is simple, tag+n or tag-n would be more flexible.

== show - history analysis ==
>
> I like "git show" and "svn log --diff" as they give me all information about 
> commit I need ...
> It would be even better if show were universal.  By "universal" I mean that, 
> ideally, it should work the same way for a tree change, file change, wiki, 
> ticket and so on.
>
>
I don't really miss this command, as it is very easy to just use the web UI
to see the differences.

But, I can see where a "fossil show" command could be handy as finfo isn't
really a variant of info for files.

== "checkout as repository" ==
>
> When you come from svn or git, the very first question is "why do I need to 
> _open_ the repository I've just cloned?".  ...
> Each of computers I use has at most one checkout of each repo.
>
>
Coming from SVN, "fossil open" was basically the same as "svn checkout"
with a different name. (I'd prefer "fossil checkout" be an alias of "fossil
open", but in Fossil it has a different function.)

The few times I have setup a local "slave" SVN repository I still had to do
"svn checkout" to create a working copy. (SVN is not a distributed VCS, so
you must commit directly to the one repository. "Slave repositories" were
introduced as a way to have a local, read-only copy of the repository, but
commits still have to go first to the "main" repo, then the slaves have to
pull from the main.)

So doing "fossil open" after doing "fossil clone" (or "fossil new") was
nothing strange or new to me.

Perhaps adding a "--open" option to the "fossil clone" and "fossil new"
commands would be a reasonable enhancement to Fossil. (I think this
approach would be cleaner than having Fossil try to guess what you are
asking it to do.)

"git clone" was weird to me at first. Also I very much used SVN's ability
to have multiple working copies checked out from a single repository. With
git I have to clone the repository to get additional working copies. And
then I have to push/pull changes between them.

== wiki syntax ==
>
> One of the weaknesses of the web interface is wiki syntax.  After you chose 
> markup format and click "Create", you have to keep formatting rules in mind.  
> ...  I would appreciate a lot if there were links to the official wiki_rules 
> and md_rules files.
>
>
This can be added by editing the header and/or footer (Admin->Skins->Header
or ->Footer). It is possible to conditionally display links based on the
page being displayed (and/or other factors).

Perhaps someone could update the default "skin" for the Fossil UI to
include a wiki help link.
___
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] Synchronizing endless loop

[Florian Balmer]

Thank you very much for looking into my issue!

I have built the server from source code with `./configure; make'. I
haven't run `make clean' as I was working inside a new directory
containing just the extracted Fossil source code.

I have now replaced the server binary with the one matching my OS from
http://pkg.freebsd.org:

Fossil version 1.36 [c24373934d] 2016-10-24 14:59:33 UTC
Compiled on Oct 28 2016 19:32:28 using gcc-4.2.1 20070831 patched
[FreeBSD] (64-bit)

The version hash is the same as for my previous server binary, and
also matches that of my Windows client executable (the official
download from fossil-scm.org).

But duh, I need a faster Internet connection ...

On my slower home line, I have always cancelled my tests after around
100 or so iterations of the synchronization operation. Today, on my
ultra-fast line at work, I noticed that the `sync -u' operation
completes after 130 iterations, but unversioned files are NOT
synchronized. The artifact receipts log shows 130 corresponding
entries, most of them consisting of only a single artifact.

If the synchronization is started without `-u', there are only 18
iterations, and 18 corresponding artifact receipts log entries for the
same commit. Each artifact receipts log entry has multiple (usually
5-10) artifacts.

So this is a somewhat inflationary use of the term "endless loop" for
my part, I'm sorry for my impatience and not waiting for my tests to
finish!

Updated problem summary
===

When adding and committing a lot of data, the synchronization
operation invoked with `fossil sync -u' emits a "server says: bad
command: uvigot ..." for each round-trip, and unversioned files are
NOT synchronized.

Moreover, the synchronization operation takes many more round-trips to
complete, and most of the corresponding artifact receipts log entries
consist of only one single artifact.

Updated steps to reproduce
==

* Use Fossil version 1.36 [c24373934d] on the server and the client
* Create a new empty repository on the server
* Clone the empty repository from the server to the client
* Add and commit a lot of files (try the Fossil /src directory)
* Add an unversioned file
* Run `fossil sync -u'

--Florian
___
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] rebuild scale-ability/data written/repo size ratio

[Warren Young]

On Oct 30, 2016, at 1:57 AM, Karel Gardas  wrote:
> 
> On Fri, Oct 28, 2016 at 7:02 PM, Warren Young  wrote:
>> On Oct 28, 2016, at 3:45 AM, Karel Gardas  wrote:
>>> 
>>> make it more scale-able and allow its real usage also for projects of
>>> bigger size.
>> 
>> How many projects are there bigger than SQLite, percentage-wise?
> 
> And does it really matter?

Sure it does.  Fossil is fast enough for SQLite, so if SQLite is “very large” 
compared to most other projects that could usefully use it, then speeding up 
Fossil amounts to spending effort on a tiny minority of users.

All of that is predicated on that first “if,” however.

>>> $ time /opt/fossil-head/bin/fossil clone
>>> http://netbsd.sonnenberger.org/ netbsd-src.fossil
>>> 
>>> It takes:
>>> 
>>> real323m2.323s
>>> user42m0.262s
>>> sys 13m18.003s
>> 
>> Okay, but compared to what?
> 
> For example Git, on the same source tree:
> 
> $ time git clone https://github.com/jsonn/src.git
> Cloning into 'src'...
> remote: Counting objects: 3725278, done.
> remote: Compressing objects: 100% (111/111), done.
> remote: Total 3725278 (delta 52), reused 0 (delta 0), pack-reused 3725166
> Receiving objects: 100% (3725278/3725278), 2.18 GiB | 773.00 KiB/s, done.
> Resolving deltas: 100% (2782525/2782525), done.
> Checking connectivity... done.
> Checking out files: 100% (176388/176388), done.
> 
> real55m20.926s
> user9m30.362s
> sys 4m50.320s

So given your other report, that rebuild takes 250 minutes of that time, then 
Fossil is within about 25% of the speed of Git, if you don’t rebuild.

>>> takes around 250 minutes on the same hardware and with the same
>>> fossil.
>> 
>> Would a --skip-rebuild option for fossil clone solve your major problem, 
>> then?
> 
> There is no such option in current fossil. Some commands (import)
> supports --no-rebuild, but clone is not among them.

I didn’t tell you to use that option, I asked if you would like that option to 
exist.

>> Rebuilding is strictly optional.  It just makes Fossil operations run faster 
>> post-clone.
> 
> That's news to me, I've thought rebuild is strictly necessary to have
> other fossil commands working

Nope.  The only reason Fossil rebuilds by default is that the clone operation 
results in a sub-optimal DB, because each cloned artifact is checked into the 
new DB separately.  You end up with a series of incremental states, none of 
which are equal to the final DB state once the clone is finished.

Rebuilding forces the SQLite instance inside Fossil to take a new look at all 
the cloned artifacts as a whole and optimize the DB for that completed 
post-clone state, rather than the series of incremental states that exist at 
each point during the clone.

> repo chksuming switching off as suggested by Nikita Borodikhin helps
> here a lot. The question is if to leave it to file-system or to fossil
> itself.

If your filesystem has strong data checksumming (as opposed to just metadata 
checksumming) then I see no reason to leave repo-cksum turned on.  Keep in mind 
that the vast majority of filesystems in common use do *not* have strong data 
checksumming, so letting repo-cksum default on is a good idea.
___
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] revert of missing files using wildcard not possible.

[Richard Hipp]

On 10/31/16, arnoldemu  wrote:
>
> But still it's not possible to revert missing files using a wildcard. I
> guess because the shell doesn't know about them and doesn't expand them and
> fossil considers the * to be a valid character in a filename.

That is correct.  That is the unix way.

I suppose this is so obvious to people who grew up with Unix that we
don't even think about it.  Are you coming from a windows background?

-- 
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] revert of missing files using wildcard not possible.

[arnoldemu]

Hi Andy,

Try this:

kevin@kevin:~$ mkdir fossil
kevin@kevin:~$ cd fossil
kevin@kevin:~/fossil$ fossil new test
project-id: 72090bfca4c8d0618530e7b7b524056a25bf4052
server-id: f38e157351c762cbdb09d581ca17e1d70cb68f0c
admin-user: kevin (initial password is "c821e4")
kevin@kevin:~/fossil$ fossil open test
project-name: 
repository: /home/kevin/fossil/test
local-root: /home/kevin/fossil/
config-db: /home/kevin/.fossil
project-code: 72090bfca4c8d0618530e7b7b524056a25bf4052
checkout: a0a2d816aee3e2bc1cb0212e9869abc17c6691d5 2016-10-31 18:50:20 UTC
tags: trunk
comment: initial empty check-in (user: kevin)
check-ins: 1
kevin@kevin:~/fossil$ touch intlace.asm
kevin@kevin:~/fossil$ touch intlace.bin
kevin@kevin:~/fossil$ touch intlace.dsk
kevin@kevin:~/fossil$ fossil add intlace*
ADDED intlace.asm
ADDED intlace.bin
ADDED intlace.dsk
kevin@kevin:~/fossil$ fossil commit -m "add files"
New_Version: 828f91088a96ba00371148edb59da15ae42ac5d4
kevin@kevin:~/fossil$ ls
intlace.asm intlace.bin intlace.dsk subdir test
kevin@kevin:~/fossil$ fossil mv intlace* subdir
RENAME intlace.asm subdir/intlace.asm
RENAME intlace.bin subdir/intlace.bin
RENAME intlace.dsk subdir/intlace.dsk
kevin@kevin:~/fossil$ fossil changes
MISSING subdir/intlace.asm
MISSING subdir/intlace.bin
MISSING subdir/intlace.dsk
kevin@kevin:~/fossil$ fossil revert subdir/intlace*
UNMANAGE subdir/intlace*
kevin@kevin:~/fossil$ fossil changes
MISSING subdir/intlace.asm
MISSING subdir/intlace.bin
MISSING subdir/intlace.dsk
kevin@kevin:~/fossil$ fossil revert "subdir/intlace*"
UNMANAGE subdir/intlace*
kevin@kevin:~/fossil$ fossil changes
MISSING subdir/intlace.asm
MISSING subdir/intlace.bin
MISSING subdir/intlace.dsk
kevin@kevin:~/fossil$ fossil revert subdir/intlace.asm
DELETE subdir/intlace.asm
REVERT intlace.asm
"fossil undo" is available to undo changes to the working checkout.
kevin@kevin:~/fossil$ fossil changes
MISSING subdir/intlace.bin
MISSING subdir/intlace.dsk
kevin@kevin:~/fossil$ 

You reverted the files in their original location. To me that doesn't make 
sense. I consider the operation to have succeeded and fossil now thinks of them 
in their new location so I revert them in their new location to go back to 
their old location. I can revert them one at a time in their new location and 
that works.

OR I could copy or create files in their new location and revert those.

But still it's not possible to revert missing files using a wildcard. I guess 
because the shell doesn't know about them and doesn't expand them and fossil 
considers the * to be a valid character in a filename.








___
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 diff: extra empty lines in non-console output on Windows

[Artur Shepilko]

Ok, just dropped the CLA in the mail.
Sure USPS has an important role in the Fossil project, it probably has
its own username in the repo too :

Below is the patch I applied to clear the described issue (not sure if
the list accepts attachments); as I mentioned earlier, it's
Windows-specific and is very much similar to how it has been patched
for "fossil cat" issue:

patch-Base:http://fossil-scm.org/index.html/info/d13fc6a6b79e71bd
---
Index: src/printf.c
==
--- src/printf.c
+++ src/printf.c
@@ -875,24 +875,33 @@
 /*
 ** Write to standard output or standard error.
 **
 ** On windows, transform the output into the current terminal encoding
 ** if the output is going to the screen.  If output is redirected into
-** a file, no translation occurs.  No translation ever occurs on unix.
+** a file, no translation occurs. Switch output mode to binary to
+** properly process line-endings, make sure to switch the mode back to
+** text when done.
+** No translation ever occurs on unix.
 */
 void fossil_puts(const char *z, int toStdErr){
+  FILE* out = (toStdErr ? stderr : stdout);
   int n = (int)strlen(z);
   if( n==0 ) return;
+  assert( toStdErr==0 || toStdErr==1 );
   if( toStdErr==0 ) stdoutAtBOL = (z[n-1]=='\n');
 #if defined(_WIN32)
   if( fossil_utf8_to_console(z, n, toStdErr) >= 0 ){
 return;
   }
+  fflush(out);
+  _setmode(_fileno(out), _O_BINARY);
 #endif
-  assert( toStdErr==0 || toStdErr==1 );
-  fwrite(z, 1, n, toStdErr ? stderr : stdout);
-  fflush(toStdErr ? stderr : stdout);
+  fwrite(z, 1, n, out);
+#if defined(_WIN32)
+  fflush(out);
+  _setmode(_fileno(out), _O_TEXT);
+#endif
 }

 /*
 ** Force the standard output cursor to move to the beginning
 ** of a line, if it is not there already.

Index: src/utf8.c
==
--- src/utf8.c
+++ src/utf8.c
@@ -317,10 +317,11 @@
   wchar_t *zUnicode; /* Unicode version of zUtf8 */
   DWORD dummy;
   Blob blob;

   static int istty[2] = { -1, -1 };
+  assert( toStdErr==0 || toStdErr==1 );
   if( istty[toStdErr]==-1 ){
 istty[toStdErr] = _isatty(toStdErr + 1) != 0;
   }
   if( !istty[toStdErr] ){
 /* stdout/stderr is not a console. */


---

NOTE: Only src/print.c contributes to the issue, src/utf8.c patch only
has an additional assert to keep it consistent with the expected
values of toStdErr, which I guess is not really required.

I did some limited testing of this on both Windows and Linux boxes
mostly to confirm that the issue is cleared. Hope this could be fully
tested and included in the 1.37 release.

And, yes, the issue was spotted from the qtcreator-plugin-fossil, just
now its Windows version got somewhat more attention.

Thanks.

On Mon, Oct 31, 2016 at 5:24 AM, Richard Hipp  wrote:
> On 10/31/16, Artur Shepilko  wrote:
>>  I would've
>> gladly fixed it myself, but have not mailed yet the Contributor Agreement..
>> (I have signed it though :)
>>
>
> Please do mail in your CLA.  And maybe also post a patch to this mailing list.
>
> --
> 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] Is FOSSIL supposed to compile with MSVC14?

[Tony Papadimitriou]

I can compile fossil just fine (with or without SSL) with MSVC12
I just installed MSVC14 and I get errors when compiling with the SSL option (no 
errors without it).

(BTW, SQLite3 also compiles OK with MSVC14).

So, I wonder if this is normal, or if I should be looking for installation / 
configuration problems in my setup.

Here’s the warnings/errors I get:

zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _free imported in 
function _zcfree
zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _free imported
zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _malloc imported 
in function _zcalloc
zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _malloc imported
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol 
___stdio_common_vsprintf imported in function __snprintf
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __wopen imported 
in function _gz_open
zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __lseeki64 
imported in function _gz_open
OLDNAMES.lib(open.obi) : warning LNK4049: locally defined symbol __open imported
libeay32.lib(pem_lib.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(txt_db.obj) : error LNK2001: unresolved external symbol ___iob_func
libeay32.lib(ui_openssl.obj) : error LNK2001: unresolved external symbol 
___iob_func
ssleay32.lib(t1_enc.obj) : error LNK2001: unresolved external symbol ___iob_func
ssleay32.lib(d1_both.obj) : error LNK2001: unresolved external symbol 
___iob_func
ssleay32.lib(s3_srvr.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol 
___iob_func
libeay32.lib(dso_win32.obj) : error LNK2019: unresolved external symbol 
_sprintf referenced in function _win32_name_converter
zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol __imp__wcstombs 
referenced in function _gz_open
zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol __imp__open 
referenced in function _gz_open
OLDNAMES.lib(open.obi) : error LNK2001: unresolved external symbol __imp__open
.\fossil.exe : fatal error LNK1120: 4 unresolved externals
NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio 
14.0\VC\BIN\link.EXE"' : return code '0x460'
Stop.

Thanks.
___
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 FOSSIL supposed to compile with MSVC14?

[Richard Hipp]

On 10/31/16, Tony Papadimitriou  wrote:
> I can compile fossil just fine (with or without SSL) with MSVC12
> I just installed MSVC14 and I get errors when compiling with the SSL option
> (no errors without it).

I don't own a copy of MSVC14, so I cannot really say.

(Aside: Earlier today, I got work from the repair shop that my win10
machine is dead and too expensive to fix.  So I don't even have a
Windows10 platform at the moment.)

Perhaps you can figure out a work-around or a fix and post patches here, Tony?

>
> (BTW, SQLite3 also compiles OK with MSVC14).
>
> So, I wonder if this is normal, or if I should be looking for installation /
> configuration problems in my setup.
>
> Here’s the warnings/errors I get:
>
> zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _free imported
> in function _zcfree
> zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _free
> imported
> zlib.lib(zutil.obj) : warning LNK4217: locally defined symbol _malloc
> imported in function _zcalloc
> zlib.lib(gzlib.obj) : warning LNK4049: locally defined symbol _malloc
> imported
> zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol
> ___stdio_common_vsprintf imported in function __snprintf
> zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __wopen
> imported in function _gz_open
> zlib.lib(gzlib.obj) : warning LNK4217: locally defined symbol __lseeki64
> imported in function _gz_open
> OLDNAMES.lib(open.obi) : warning LNK4049: locally defined symbol __open
> imported
> libeay32.lib(pem_lib.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> libeay32.lib(txt_db.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> libeay32.lib(ui_openssl.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> ssleay32.lib(t1_enc.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> ssleay32.lib(d1_both.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> ssleay32.lib(s3_srvr.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> libeay32.lib(cryptlib.obj) : error LNK2001: unresolved external symbol
> ___iob_func
> libeay32.lib(dso_win32.obj) : error LNK2019: unresolved external symbol
> _sprintf referenced in function _win32_name_converter
> zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol
> __imp__wcstombs referenced in function _gz_open
> zlib.lib(gzlib.obj) : error LNK2019: unresolved external symbol __imp__open
> referenced in function _gz_open
> OLDNAMES.lib(open.obi) : error LNK2001: unresolved external symbol
> __imp__open
> .\fossil.exe : fatal error LNK1120: 4 unresolved externals
> NMAKE : fatal error U1077: '"C:\Program Files (x86)\Microsoft Visual Studio
> 14.0\VC\BIN\link.EXE"' : return code '0x460'
> Stop.
>
> Thanks.
>


-- 
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] fossil diff: extra empty lines in non-console output on Windows

[Richard Hipp]

On 10/31/16, Adam Jensen  wrote:
>
> Would a GPG signed statement suffice? (It doesn't apply to me; I'm just
> generally curious). How attached to paper and scribbling is the legal
> system?

I am attached to dead-tree documents.  With prior approval, an email
scan can be used instead of sending the original paper via post.
-- 
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] fossil diff: extra empty lines in non-console output on Windows

[Adam Jensen]

On 10/31/2016 06:24 AM, Richard Hipp wrote:
> On 10/31/16, Artur Shepilko  wrote:
>>  I would've
>> gladly fixed it myself, but have not mailed yet the Contributor Agreement..
>> (I have signed it though :)
>>
> 
> Please do mail in your CLA.  And maybe also post a patch to this mailing list.
> 

Would a GPG signed statement suffice? (It doesn't apply to me; I'm just
generally curious). How attached to paper and scribbling is the legal
system?

___
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 diff: extra empty lines in non-console output on Windows

[Richard Hipp]

On 10/31/16, Artur Shepilko  wrote:
>  I would've
> gladly fixed it myself, but have not mailed yet the Contributor Agreement..
> (I have signed it though :)
>

Please do mail in your CLA.  And maybe also post a patch to this mailing list.

-- 
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] Synchronizing endless loop

[Andy Bradford]

Thus said "Andy Bradford" on 30 Oct 2016 23:35:46 -0600:

> > Sync with http://some.fossil.server/fossil.cgi/test-repo
> > Round-trips: 2   Artifacts sent: 3  received: 0
> > Error: bad command: uvigot home.wiki 1477722315
> > ecb1c59ef204582770184dfc6ddc3f7451224c94 416
> 
> This error would  seem to indicate that your client  sync code doesn't
> actually know  what the uvigot  card is (even  though it does  seem to
> know what -u is). Did you build the client from source? If so, did you
> run ``make clean'' prior to configuring and building?

Correction, after  looking at the code,  this appears to be  coming from
the server:

http://www.fossil-scm.org/index.html/artifact/0d5ab26abbb86680?ln=1564,1567

So the questions I asked above apply to the server version you reported.

Thanks,

Andy
-- 
TAI64 timestamp: 40005816e70b


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