Re: [fossil-users] Unversioned content for distribution

[David Mason]

Actually it's not clear what revert does. I removed the file and revert
didn't recover it. I created an empty file and revert didn't recover it.
(But maybe this is timestamp related, or because I'm on the machine that
created the uv file in the first place.)

Thanks  ../Dave

On 14 June 2017 at 01:41, David Mason  wrote:

> `fossil uv list` doesn't mention any path information. Does it have path
> information behind the scenes so that `fossil uv revert` can put the file
> in the original place?
>
> Is there a way to find if any unversioned file has been updated apart from
> looking at the hash or the date for particular files?
>
> Thanks  ../Dave
>
> On 14 June 2017 at 01:32, David Mason  wrote:
>
>> I finally got around to this, but I got the following errors on Linux:
>> : ~/Sites/p4ru/kitPJS ; fossil unversioned revert
>> Usage: fossil sync URL
>> : ~/Sites/p4ru/kitPJS ; fossil ver
>> This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
>> : ~/Sites/p4ru/kitPJS ; fossil unversioned list
>> 504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
>> : ~/Sites/p4ru/kitPJS ; fossil sync -u
>> Usage: fossil sync URL
>> : ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
>>22347960  378207
>>
>> I downloaded this version today from the website. On MacOSX, `fossil sync
>> -u` seems to work fine (as does `fossil unver revert`). It's good that cat
>> works, but revert seems nicer!
>>
>> Thanks ../Dave
>>
>> On 10 May 2017 at 09:34, David Mason  wrote:
>>
>>> Perfect! I knew it would be easy.
>>>
>>> Thanks
>>>
>>> On 10 May 2017 at 07:04, Richard Hipp  wrote:
>>>
 On 5/10/17, David Mason  wrote:
 > I have a fossil repo and in it I have a file foo.js that is generated
 by my
 > build process - so I don't want it versioned. But I *do* want it
 > distributed, and want it referencable from foo.html - which *is*
 versioned.
 > foo.html and foo.js are *not* served by fossil, but by a simple
 apache or
 > nginx server.
 >
 > So in my working directory I create foo.js and then do what to get it
 moved
 > to the master fossil repo.

 fossil uv add foo.js
 fossil uv sync


 > Then on my production machine I do what command
 > to get the current version of foo.js from the master fossil repo?

 fossil uv sync
 fossil uv export foo.js foo.js
 OR:  fossil uv cat foo.js >foo.js

 >
 > I'm sure it's easy, but the documentation does not give me guidance
 on this
 > simple use-case.
 >
 > Thanks  ../Dave
 >


 --
 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] Unversioned content for distribution

[David Mason]

`fossil uv list` doesn't mention any path information. Does it have path
information behind the scenes so that `fossil uv revert` can put the file
in the original place?

Is there a way to find if any unversioned file has been updated apart from
looking at the hash or the date for particular files?

Thanks  ../Dave

On 14 June 2017 at 01:32, David Mason  wrote:

> I finally got around to this, but I got the following errors on Linux:
> : ~/Sites/p4ru/kitPJS ; fossil unversioned revert
> Usage: fossil sync URL
> : ~/Sites/p4ru/kitPJS ; fossil ver
> This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
> : ~/Sites/p4ru/kitPJS ; fossil unversioned list
> 504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
> : ~/Sites/p4ru/kitPJS ; fossil sync -u
> Usage: fossil sync URL
> : ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
>22347960  378207
>
> I downloaded this version today from the website. On MacOSX, `fossil sync
> -u` seems to work fine (as does `fossil unver revert`). It's good that cat
> works, but revert seems nicer!
>
> Thanks ../Dave
>
> On 10 May 2017 at 09:34, David Mason  wrote:
>
>> Perfect! I knew it would be easy.
>>
>> Thanks
>>
>> On 10 May 2017 at 07:04, Richard Hipp  wrote:
>>
>>> On 5/10/17, David Mason  wrote:
>>> > I have a fossil repo and in it I have a file foo.js that is generated
>>> by my
>>> > build process - so I don't want it versioned. But I *do* want it
>>> > distributed, and want it referencable from foo.html - which *is*
>>> versioned.
>>> > foo.html and foo.js are *not* served by fossil, but by a simple apache
>>> or
>>> > nginx server.
>>> >
>>> > So in my working directory I create foo.js and then do what to get it
>>> moved
>>> > to the master fossil repo.
>>>
>>> fossil uv add foo.js
>>> fossil uv sync
>>>
>>>
>>> > Then on my production machine I do what command
>>> > to get the current version of foo.js from the master fossil repo?
>>>
>>> fossil uv sync
>>> fossil uv export foo.js foo.js
>>> OR:  fossil uv cat foo.js >foo.js
>>>
>>> >
>>> > I'm sure it's easy, but the documentation does not give me guidance on
>>> this
>>> > simple use-case.
>>> >
>>> > Thanks  ../Dave
>>> >
>>>
>>>
>>> --
>>> 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] Unversioned content for distribution

[David Mason]

I finally got around to this, but I got the following errors on Linux:
: ~/Sites/p4ru/kitPJS ; fossil unversioned revert
Usage: fossil sync URL
: ~/Sites/p4ru/kitPJS ; fossil ver
This is fossil version 2.2 [81d7d3f43e] 2017-04-11 20:54:55 UTC
: ~/Sites/p4ru/kitPJS ; fossil unversioned list
504e6cf08911 2017-06-14 00:45:18   37820760173 index.js
: ~/Sites/p4ru/kitPJS ; fossil sync -u
Usage: fossil sync URL
: ~/Sites/p4ru/kitPJS ; fossil unver cat index.js|wc
   22347960  378207

I downloaded this version today from the website. On MacOSX, `fossil sync
-u` seems to work fine (as does `fossil unver revert`). It's good that cat
works, but revert seems nicer!

Thanks ../Dave

On 10 May 2017 at 09:34, David Mason  wrote:

> Perfect! I knew it would be easy.
>
> Thanks
>
> On 10 May 2017 at 07:04, Richard Hipp  wrote:
>
>> On 5/10/17, David Mason  wrote:
>> > I have a fossil repo and in it I have a file foo.js that is generated
>> by my
>> > build process - so I don't want it versioned. But I *do* want it
>> > distributed, and want it referencable from foo.html - which *is*
>> versioned.
>> > foo.html and foo.js are *not* served by fossil, but by a simple apache
>> or
>> > nginx server.
>> >
>> > So in my working directory I create foo.js and then do what to get it
>> moved
>> > to the master fossil repo.
>>
>> fossil uv add foo.js
>> fossil uv sync
>>
>>
>> > Then on my production machine I do what command
>> > to get the current version of foo.js from the master fossil repo?
>>
>> fossil uv sync
>> fossil uv export foo.js foo.js
>> OR:  fossil uv cat foo.js >foo.js
>>
>> >
>> > I'm sure it's easy, but the documentation does not give me guidance on
>> this
>> > simple use-case.
>> >
>> > Thanks  ../Dave
>> >
>>
>>
>> --
>> 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] progress on fossil 2.0?

[Brooks, Phil]

Hi,



I recently came across this page discussing potential features of a Fossil 2.0, 
and was wondering if any progress has been made toward any of these:



http://www.fossil-scm.org/index.html/info/0e047901c2f4a07d8110f7bb9a94c92b56202700



I am especially interested in:

  *   Partial clones - the ability to clone only recent additions, ignoring 
older history.

  *   Checkout from and commit to a remote repository (via HTTP/HTTPS) without 
having to clone. (The implementation would likely be to create a "partial 
clone" of just the one check-in that is being checked out.)

  *   "Slices" - the ability to checkout, edit, and commit against a 
subdirectory of the complete source tree.

For the "Slices" feature, we could actually use something a little more finely 
grained than that, allowing the ability to checkout, edit and commit individual 
files from anywhere in the complete source tree.  We do this quite frequently 
with CVS and the model doesn't seem to have support from any other modern VCS.  
In CVS, you can say:



cvs update foo/bar.C baz/goo.h Makefile



and it will let you check them out, change them and check them back in. (I 
realize that this is because it is only really managing individual files in the 
first place).



I would like to be able to do something like:



fossil open /myrepos/foo.fossil foo/bar.C baz/goo.h Makefile



and have only those files get checked out - then, when I do a check-in, it 
would be the same as if I had checked everything out, made the changes and then 
done a checkin of that full set with all of the other files unchanged.  
Similarly, pull/update would allow me to update only the files I have checked 
out.



Phil
___
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] What is the best way to update to a new upstream version

[The Tick]

On 6/13/2017 3:05 PM, Joerg Sonnenberger wrote:

On Tue, Jun 13, 2017 at 02:44:31PM -0500, The Tick wrote:

Thanks, that is what I was looking for. I've set up a test respository and
things look good until I get to the final "merge" step:

$ f init F.fossil
$ f open F.fossil
$ f add project
$ f commit --tag 1.5 --branch Official
$ f tag add --propagate Official 0dd97cd973

$ f co trunk
$ f add project
$ f commit


This part is the problem. You are missing the merge of 1.5 unto trunk.



That did it -- very cool. Thanks.

$ f init F.fossil
$ f open F.fossil
$ f add project/
$ f commit --tag 1.5 --branch Official
$ f tag add --propagate Official 1.5

$ f co trunk
$ f merge 1.5
$ f commit
# Make some local changes
$ f commit

$ f co Official
# Remove all files and unpack latest version
$ f addremove
$ f commit --tag 1.6

$ f co trunk
$ f merge 1.6
$ f commit

___
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] What is the best way to update to a new upstream version

[Joerg Sonnenberger]

On Tue, Jun 13, 2017 at 02:44:31PM -0500, The Tick wrote:
> Thanks, that is what I was looking for. I've set up a test respository and
> things look good until I get to the final "merge" step:
> 
> $ f init F.fossil
> $ f open F.fossil
> $ f add project
> $ f commit --tag 1.5 --branch Official
> $ f tag add --propagate Official 0dd97cd973
> 
> $ f co trunk
> $ f add project
> $ f commit

This part is the problem. You are missing the merge of 1.5 unto trunk.

Joerg
___
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] What is the best way to update to a new upstream version

[The Tick]

On 6/13/2017 12:52 PM, Joerg Sonnenberger wrote:

On Tue, Jun 13, 2017 at 12:17:46PM -0500, The Tick wrote:

Given a repository based on a previously fetched version of some software
package and having been modified with local changes, what is the best way to
update to a more recent version of the upstream package?


The best approach is still to kind of emulate what CVS is doing with
vendor branches. It works best if you start from scratch, but with some
work it can be fixed up later:

- Create a branch off the initial empty commit for this package.
- Put the sources into the correct subdirectory, addremove.
- Commit, possibly with a tag including the package name and version.
- Now merge that branch into trunk.
- Commit local changes on top.

If you want to update:

- Checkout the branch.
- Remove all files, put the sources into the correct subdirectory,
  addremove.
- Commit.
- Merge the branch into trunk.
- Fix any conflicts.



Thanks, that is what I was looking for. I've set up a test respository 
and things look good until I get to the final "merge" step:


$ f init F.fossil
$ f open F.fossil
$ f add project
$ f commit --tag 1.5 --branch Official
$ f tag add --propagate Official 0dd97cd973

$ f co trunk
$ f add project
$ f commit

#Make some local changes

$ f commit

At this point things look pretty good. I've got a branch "Official" and 
my "trunk" has my local changes. Now I download the latest official version.


$ f co Official
# Remove all files and unpack newest upstream version
# I guess I do an "addremove" here.
$ f commit --tag 1.6

Again, things are looking good. I've got the latest upstream version 
into branch "Official"


$ f co trunk

Now, how do I "merge"?

$ f merge -n Official
WARNING: no common ancestor for project/graph1.tcl
WARNING: no common ancestor for project/graph2.tcl
REMINDER: this was a dry run - no files were actually changed.
$ f merge -n 1.6
WARNING: no common ancestor for project/graph1.tcl
WARNING: no common ancestor for project/graph2.tcl
REMINDER: this was a dry run - no files were actually changed.
MSYS2 /tmp/f
$ f merge -n a85895dba5
WARNING: no common ancestor for project/graph1.tcl
WARNING: no common ancestor for project/graph2.tcl
REMINDER: this was a dry run - no files were actually changed.


___
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] What is the best way to update to a new upstream version

[Joerg Sonnenberger]

On Tue, Jun 13, 2017 at 12:17:46PM -0500, The Tick wrote:
> Given a repository based on a previously fetched version of some software
> package and having been modified with local changes, what is the best way to
> update to a more recent version of the upstream package?

The best approach is still to kind of emulate what CVS is doing with
vendor branches. It works best if you start from scratch, but with some
work it can be fixed up later:

- Create a branch off the initial empty commit for this package.
- Put the sources into the correct subdirectory, addremove.
- Commit, possibly with a tag including the package name and version.
- Now merge that branch into trunk.
- Commit local changes on top.

If you want to update:

- Checkout the branch.
- Remove all files, put the sources into the correct subdirectory,
  addremove.
- Commit.
- Merge the branch into trunk.
- Fix any conflicts.

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

[fossil-users] What is the best way to update to a new upstream version

[The Tick]

Given a repository based on a previously fetched version of some 
software package and having been modified with local changes, what is 
the best way to update to a more recent version of the upstream package?


A "f addremove" would import the new version but would lose all local 
changes.


What I've done so far is to "f diff --unified -r X" where X is 
the commit of the last upstream version. I can now apply my patches to 
the new version before I do an "addremove". Once the "addremove" is 
done, I would make further changes if necessary.


In the above scenario, how many and when would one commit? After the 
unpack of the latest version? After applying my local patches? After 
getting the whole thing to work again? Maybe a combination of the above?


Is there a way to get fossil to carry forward the local changes for me 
somehow? Is there a better way than what I've outlined?


With RCS I used to file any local changes into a new branch: for version 
X.Y of a package, I would checkin my changes as X.Y.1.0, etc. When there 
was a new version X.Z, I could checkin as version X.Z and then do a 
"rcsdiff -u -r X.Y -r X.Y.1.n" which I could apply to the new version 
X.Z and when all is working again, checkin the new branch X.Z.1.


Maybe there's a way to do the same with fossil (and I did not because I 
don't know how).



___
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] src/blob.c : blob_read_from_file overflow int size

[Stephan Beal]

On Tue, Jun 13, 2017 at 3:03 PM, Martin Gagnon  wrote:

> However, I think the best types for Blob structure is probably size_t.
> I'm not sure if it's okay to use size_t with C89, but fossil already use
> it in some places (even in blob.c), so I guess it's not a problem.
>

Insofar as i can find, size_t is defined in C89, but i'm not sure which
header. C99 appears to define it in stddef.h.

man malloc

shows size_t in the function signature, and malloc() is C89.

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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] src/blob.c : blob_read_from_file overflow int size

[Martin Gagnon]

On Tue, Jun 13, 2017 at 04:19:53PM +0900, kowlsd3pw...@yahoo.co.jp wrote:
> 
>  [837333fc] Fix the blob_read_from_file  
> thank you.

Actually, it is not completely fix because blob_read_from_file() call
blob_read_from_channel() which return a int. 

Anyway, since the internals of the Blob structure use "unsigned int" to
track size and all other functions that deal with Blobs expect "int" or
"unsigned int", it would require a lot more changes to really make it
works for really big files. 

The question is, Does it really worth it? Knowing that it would probably
slow down for 99.99% of the case, especially on older non 64bit
architectures.

However, I think the best types for Blob structure is probably size_t.
I'm not sure if it's okay to use size_t with C89, but fossil already use
it in some places (even in blob.c), so I guess it's not a problem.

Regards,

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

[fossil-users] Feature request : mimetype suffixes pas, pp, php, vbs, cpp, 7z

[kowlsd3pw23s]

Feature request

src/doc.c : 
https://www.fossil-scm.org/index.html/artifact?ln=75=e21c027580de8bf3
aMime[]

mimetypes based on file suffixes

Delphi source file
{ "pas",    3, "text/plain"    },

Free pascal source file
{ "pp", 2, "text/plain"    },

PHP script source file
{ "php",    3, "text/plain"    },

VBScript source file
{ "vbs",    3, "text/plain"    },

C++ source file (Microsoft C++, embarcadero C++, Atmel Studio)
{ "cpp",    3, "text/plain"    },

7z archive file
{ "7z", 2, "application/x-7z-compressed"   },___
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] Bug: Unable to clone

[Roy Keene]

Richard,

That seems to have fixed it:


$ cd ~/devel/aurae
$ /home/rkeene/devel/fossil/fossil version
This is fossil version 2.3 [3200a7c72e] 2017-06-13 05:12:55 UTC
$ /home/rkeene/devel/fossil/fossil rebuild
  100.0% complete...
rebuilding the search index... done
$ rm -f /tmp/x.repo; /home/rkeene/devel/fossil/fossil clone 
~/devel/aurae/.repo /tmp/x.repo
Repository cloned into /tmp/x.repo
Rebuilding repository meta-data...
  100.0% complete...
Extra delta compression...
Vacuuming the database...
project-id: 6f28ae81cd49eaeaa8d55ac7bd1bad5ef71c4ad4
server-id:  09c7831f6f8b06a5dc2497431444a4f3961ffec2
admin-user: rkeene (password is "010b01")
$ /home/rkeene/devel/fossil/fossil fts
check-in search: on
document search: on
ticket search:   on
wiki search: on
Porter stemmer:  on
full-text index: enabled
documents:   3515
$

Thanks,
Roy Keene


On Tue, 13 Jun 2017, Richard Hipp wrote:


On 6/13/17, Roy Keene  wrote:

Richard,

No change.



I checked in a change (to trunk) that seems likely to fix this.
Please try yet again using the latest trunk.
--
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] src/blob.c : blob_read_from_file overflow int size

[Stephan Beal]

On Tue, Jun 13, 2017 at 9:10 AM,  wrote:

> Nobody will put big files, but there are logic defects
>
> int size;
>
> file size is  INT_MAX + 1 then size is negative(INT_MIN)
>

Actually, that's not guaranteed. The C standard guarantees
overflow/underflow behaviour only for unsigned integers. For signed
integers, over/underflow have undefined results. (However, every machine i
have ever tested this on does wrap predictably for signed integers.)

-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
"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] blob.c : blob_trim , cast unsigned int into int, and re-cast

[kowlsd3pw23s]

blob.c : blob_trim
  line 538

  https://www.fossil-scm.org/index.html/artifact?ln=538=febcddb2025c8da7

p->nUsed is unsigned int
but while loop is int

   538    int n = p->nUsed;
   539    while( n>0 && fossil_isspace(z[n-1]) ){ n--; }
   540    p->nUsed = n;___
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] src/blob.c : blob_read_from_file overflow int size

[kowlsd3pw23s]

 [837333fc] Fix the blob_read_from_file  
thank you.
___
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] src/blob.c : blob_read_from_file overflow int size

[kowlsd3pw23s]

Nobody will put big files, but there are logic defects

int size;

file size is  INT_MAX + 1 then size is negative(INT_MIN)

file size is UINT_MAX + 2 then size is 1___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users