Re: [fossil-users] Unversioned files not accessible from Webinterface

[Richard Hipp]

On 2/22/17, Tony Papadimitriou  wrote:
> Unless the repo visitor happens
> to magically know about this /uvlist link there seems to be no obvious way
> to get to it starting navigation from some main page.

That is by design.  The intent is that the repository designer will
create a link to the /uvlist page on the homepage or on the menu or
some other appropriate place, if she intends for the /uvlist page to
be used.

On the Fossil self-hosting repository, the Download menu item is  a
link to a specific file in the /uv hierarchy that contains a formatted
list of unversioned files.  Knowledgeable users are free to visit
https://www.fossil-scm.org/fossil/uvlist if they like, but that is not
a page that we especially want to call to the attention of newbies.
-- 
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] Unversioned files not accessible from Webinterface

[Tony Papadimitriou]

Thank you for the tip, good to know.
(However, I think my point is still valid.  Unless the repo visitor happens to 
magically know about this /uvlist link there seems to be no obvious way to get 
to it starting navigation from some main page.)
From: Martin Gagnon 

To see the list of unversioned files on a repo, use the /uvlist page: 
example: https://www.fossil-scm.org/index.html/uvlist
___
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 files not accessible from Web interface

[Martin Gagnon]

 Sorry my bad,  I was confused because on the main page the footer of the
page shows 1.34,   but I just notice that when going inside one repository
it's 1.36.

-- 
Martin G.

Le mer. 22 févr. 2017 à 11:45, Roy Keene  a écrit :

> ChiselApp runs Fossil 1.36 currently, not 1.34.
>
> On Wed, 22 Feb 2017, Martin Gagnon wrote:
>
> >
> > Le mer. 22 févr. 2017 à 03:33, Tony Papadimitriou  a
> écrit :
> >   I placed some unversioned file to a chiselapp repo I maintain and
> then from the Web UI tried to locate the file but without luck.
> > There isn?t even a hint that some unversioned file is in the repo, so
> that one can try to UNV SYNC from the command line (after cloning).
> >
> > Maybe the FILES tab should have an additional option (next to All,
> Tree-View, etc.) for Unversioned?  And from there process them (e.g.,
> download, hex) exactly the same.
> >
> >
> >
> > Hi Tony,
> >
> > To see the list of unversionned files on a repo, use the /uvlist page:
> >
> >  example: https://www.fossil-scm.org/index.html/uvlist
> >
> > But in your case, I'm afraid that Chiselapp use a too old version of
> fossil (1.34). unversionned files feature appear in 1.36.
> >
> > May be "unver sync" command could return an error in that case?
> >
> > 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 mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Unversioned files not accessible from Web interface

[Roy Keene]

ChiselApp runs Fossil 1.36 currently, not 1.34.

On Wed, 22 Feb 2017, Martin Gagnon wrote:



Le mer. 22 févr. 2017 à 03:33, Tony Papadimitriou  a écrit :
  I placed some unversioned file to a chiselapp repo I maintain and then 
from the Web UI tried to locate the file but without luck.
There isn?t even a hint that some unversioned file is in the repo, so that one 
can try to UNV SYNC from the command line (after cloning).
 
Maybe the FILES tab should have an additional option (next to All, Tree-View, 
etc.) for Unversioned?  And from there process them (e.g., download, hex) 
exactly the same.
 


Hi Tony, 

To see the list of unversionned files on a repo, use the /uvlist page: 

 example: https://www.fossil-scm.org/index.html/uvlist

But in your case, I'm afraid that Chiselapp use a too old version of fossil 
(1.34). unversionned files feature appear in 1.36.

May be "unver sync" command could return an error in that case? 

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

Re: [fossil-users] Unversioned files not accessible from Web interface

[Martin Gagnon]

Le mer. 22 févr. 2017 à 03:33, Tony Papadimitriou  a écrit :

> I placed some unversioned file to a chiselapp repo I maintain and then
> from the Web UI tried to locate the file but without luck.
> There isn’t even a hint that some unversioned file is in the repo, so that
> one can try to UNV SYNC from the command line (after cloning).
>
> Maybe the FILES tab should have an additional option (next to All,
> Tree-View, etc.) for Unversioned?  And from there process them (e.g.,
> download, hex) exactly the same.
>
>

Hi Tony,

To see the list of unversionned files on a repo, use the /uvlist page:

 example: https://www.fossil-scm.org/index.html/uvlist

But in your case, I'm afraid that Chiselapp use a too old version of fossil
(1.34). unversionned files feature appear in 1.36.

May be "unver sync" command could return an error in that case?

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

Re: [fossil-users] Unversioned files.

[Arseniy Terekhin]

Really like unversioned files feature.

On windows you can't do 'fossil uv add ajax\index.html', only forward
slashes will work. Which is okay, but I'd prefer fossil to do slash
replacing.

On Tue, Aug 30, 2016 at 9:31 PM, Richard Hipp  wrote:

> A new feature of Fossil (currently unreleased and only available to
> people who are willing to recompile the code on trunk) is "unversioned
> files".
>
> https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki
>
> The "Download" page on the canonical Fossil website is now implemented
> using these unversioned files, which means that mirrors that sync with
> the -u option also mirror the Download page content.
>
> Your feedback on this new feature is appreciated.
>
> --
> 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
>



-- 
I remain,
Arseniy Terekhin
___
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 files.

[Adam Jensen]

On 09/12/2016 02:55 PM, Ross Berteig wrote:
> Clumsy, perhaps, but it would work today.

Thanks. The `fossil fusefs ...` performance kills the possibility of
using Fossil as a large binary file repository manager.

I find myself casually reading "Practical File System Design"[1] and the
HDF5 Specs[2] and generally imagining what the requirements for a modern
[instrumentation data] repository might be. If anyone wishes to discuss
such a thing or otherwise share ideas, they are welcome to contact me.

[1]:
https://ia600404.us.archive.org/29/items/practical-file-system-design/practical-file-system-design.pdf
[2]: https://www.hdfgroup.org/HDF5/doc/Specs.html
___
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 files.

[Ross Berteig]

On 9/12/2016 5:59 AM, Ron W wrote:

On Sun, Sep 11, 2016 at 12:18 PM, Adam Jensen > wrote:

The phrase "ephemeral content" is a bit disconcerting. It suggests
values and attitudes towards this data which will probably be reflected
in the requirements, specification, and implementation of the software.

In the use-case I have in mind, this data would be "immutable content"
and should be considered precious. The goals would be to avoid
accidental loss and/or corruption. It isn't a low-value, fleeting
scratch-pad that would be thrown away on a regular basis.


Unversioned means that if the file is committed again, the new contents
will replace the current contents.

If you only ever commit the (unversioned) file once, then it's contents
will remain.


In current fossil, the way to create a permanent and immutable file is 
to check it in. It can be thereafter (immutably) recovered by knowing 
its name and version, which can be summarized by its SHA1 hash. Syncing 
to multiple copies of the repository and taking backups improves the 
security of the data, but nothing can modify an artifact after it is 
checked in.



I suppose, what you are looking for is a mechanism for preventing
further commits to those files, therefore preventing the contents from
being replaced.

Perhaps marking the file as a "closed leaf" could be used as a means to
achieve this immutability you are seeking.


That would prevent further work on a branch containing that file, but 
only if that branch were the only branch holding the file. But then it 
would only be visible in the file system in a checkout of that specific 
branch. That would put a sizable crimp on the utility of such a file.


That said, using a closed branch as a parking place for the data could 
work if combined with a build script that used "fossil artifact" to 
extract the immutable data files.


If the data did need to mutate, you would reopen the branch and checkin 
the change. Then back on the the development branch you would edit that 
build script to request the new artifact ID.


Clumsy, perhaps, but it would work today.


There might be some value to being able to mark a file as "locked" 
somehow. Problem is that tags only relate to manifests, not to the 
individual files inside. I think it would require an extension to the 
manifest format (and the table schema too) to support such a per-file lock.


But for some kinds of files, having a stumbling block that prevents 
casual changes might have sufficient value to be worth implementing in 
fossil itself. Without per-file tagging, you could have a build script 
that verifies the "immutable" files have not mutated, and then require 
that script be edited if a reason to update the immutable data is 
discovered.


--
Ross Berteig   r...@cheshireeng.com
Cheshire Engineering Corp.   http://www.CheshireEng.com/
+1 626 303 1602
___
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 files.

[Ron W]

On Sun, Sep 11, 2016 at 12:18 PM, Adam Jensen  wrote:
>
> The phrase "ephemeral content" is a bit disconcerting. It suggests
> values and attitudes towards this data which will probably be reflected
> in the requirements, specification, and implementation of the software.
>
> In the use-case I have in mind, this data would be "immutable content"
> and should be considered precious. The goals would be to avoid
> accidental loss and/or corruption. It isn't a low-value, fleeting
> scratch-pad that would be thrown away on a regular basis.
>

Unversioned means that if the file is committed again, the new contents
will replace the current contents.

If you only ever commit the (unversioned) file once, then it's contents
will remain.

I suppose, what you are looking for is a mechanism for preventing further
commits to those files, therefore preventing the contents from being
replaced.

Perhaps marking the file as a "closed leaf" could be used as a means to
achieve this immutability you are seeking.
___
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 files.

[Adam Jensen]

On 09/11/2016 05:30 PM, Stephan Beal wrote:
> And i would argue against it as falling well out of scope for an SCM ;)

I'm okay with that.
___
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 files.

[Adam Jensen]

On 09/11/2016 06:38 PM, Scott Robison wrote:
> Of course, adding differentiation and specialization increases
> complexity, so it can be a tricky balancing act. 

We, as a species, have already gone down that rabbit hole.
___
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 files.

[Scott Robison]

On Sun, Sep 11, 2016 at 3:27 PM, Adam Jensen  wrote:

> On 09/11/2016 04:42 PM, Scott Robison wrote:
> > I may not be understanding you, but from my point of view, it already
> > does what you want by supporting versioned files that you simply never
> > change. For example, you could have a repo that has a structure along
> > the lines of:
> >
> > /root/static-data/ -> a place to store lots of big binary blobs that you
> > don't intent to ever modify.
> >
> > /root/dynamic-data/ -> a place to store things that you want to track
> > the history for
> >
> > Is this inadequate? If so, how or why?
>
> My impression is that with a different class of files, the operations,
> interface, and underlying implementation can be specialized for the
> qualities, characteristics, and various needs that are peculiar to that
> class. For example, an unversioned file might avoid some of the CPU,
> memory, and/or storage requirements that are involved in versioned
> files. Also, I imagine there might be some specialized commands and
> alerts associated with the two major use-cases for unversioned files
> (critical immutable data, and temporary intermediate data).
>

You are generally correct that a specialized solution can often improve on
the generalized solution by some metric. There are ways to do things with
huge files (such as diff them) that wouldn't strictly require as much
memory as the general case does, but the utility is marginal at best for
fossil's design case. Very few people would have a need to compute deltas
for a terabyte sized file, so it is not implemented. Not that you were
suggesting someone should be able to do that, I was just going for the
first very ridiculous idea that came to mind.

In any case, it might be possible to make the unversioned functionality
"better" in some way, but it seems like a less than ideal use of time IMO.
Fossil already handles the critical file tracking for versioned files, just
don't overwrite them. And if at some point you discover that the critical
data really is wrong or outdated, you can commit a new version over the old
one. In essence, the unversioned critical data functionality you've
envisioned works off the assumption that you can see into the future and
guarantee you'll never change your mind about the utility of versioning for
these files. YMMV

As SB said, it's just an opinion, and not one that drives the project. I
just wanted to try to understand what you were hoping to gain from it, so
thanks for answering my questions.


>
> Ultimately, I suppose the purpose of a tool like Fossil is to assist in
> the management of complexity. Differentiation and specialization seems
> like a fundamental part of that. But yeah, my tests all currently make
> use of the versioned file class for storage.


Of course, adding differentiation and specialization increases complexity,
so it can be a tricky balancing act.
-- 
Scott Robison
___
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 files.

[Stephan Beal]

On Sep 11, 2016 21:49, "Adam Jensen"  wrote:
>
> On 09/11/2016 01:54 PM, Stephan Beal wrote:
> > On Sep 11, 2016 18:18, "Adam Jensen"  > > wrote:
> [snip]
> >> '''
> >> 5.4 Unversioned File Sync
> >>
> >> "Unversioned files" are files held in the repository where only the
most
> >> recent version of the file is kept rather than the entire change
> >> history. Unversioned files are intended to be used to store ephemeral
> >> content, such as compiled binaries of the most recent release.
> >> '''
> >>
> >> The phrase "ephemeral content" is a bit disconcerting. It suggests
> >> values and attitudes towards this data which will probably be reflected
> >> in the requirements, specification, and implementation of the software.
> >>
> >> In the use-case I have in mind, this data would be "immutable content"
> >> and should be considered precious.
> >
> > That's not, as i understand it, the intention of unversioned filed.
> > Anything "important" needs to be checked in (versioned). Unversioned
> > files are primarily intended for hosting pre-built binaries and such.
>
> We might not be intersecting on this point; a perspective difference, I
> suspect. What I am suggesting is that the current intention of
> unversioned files might need be slightly tweaked to encourage an
> additional use-case where the repository supports the organization and
> management of critical data (immutable; a snap-shot of reality; large
> binary files) in addition to highly revised text files such as data
> analysis scripts, annotations, and documentation.

And i would argue against it as falling well out of scope for an SCM ;).
(Not that my opinion on the topic matters. ;) Unversioned files were, as i
understand it (possibly incorrectly), added primarily as a convenience for
a nearly-universal need/use case: hosting pre-built copies of sources held
in the SCM. Stretching that to cover a wide range of cases (some arguably
better-suited to scalable cloud infrastructure) sounds unnecessary to me.
But that's just me, and i historically tend to hold minority opinions, so
take what i say with a grain of salt.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
___
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 files.

[Adam Jensen]

On 09/11/2016 04:42 PM, Scott Robison wrote:
> I may not be understanding you, but from my point of view, it already
> does what you want by supporting versioned files that you simply never
> change. For example, you could have a repo that has a structure along
> the lines of:
> 
> /root/static-data/ -> a place to store lots of big binary blobs that you
> don't intent to ever modify.
> 
> /root/dynamic-data/ -> a place to store things that you want to track
> the history for
> 
> Is this inadequate? If so, how or why?

My impression is that with a different class of files, the operations,
interface, and underlying implementation can be specialized for the
qualities, characteristics, and various needs that are peculiar to that
class. For example, an unversioned file might avoid some of the CPU,
memory, and/or storage requirements that are involved in versioned
files. Also, I imagine there might be some specialized commands and
alerts associated with the two major use-cases for unversioned files
(critical immutable data, and temporary intermediate data).

Ultimately, I suppose the purpose of a tool like Fossil is to assist in
the management of complexity. Differentiation and specialization seems
like a fundamental part of that. But yeah, my tests all currently make
use of the versioned file class for storage.
___
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 files.

[Scott Robison]

On Sun, Sep 11, 2016 at 1:49 PM, Adam Jensen  wrote:

> On 09/11/2016 01:54 PM, Stephan Beal wrote:
> > On Sep 11, 2016 18:18, "Adam Jensen"  > > wrote:
> [snip]
> >> '''
> >> 5.4 Unversioned File Sync
> >>
> >> "Unversioned files" are files held in the repository where only the most
> >> recent version of the file is kept rather than the entire change
> >> history. Unversioned files are intended to be used to store ephemeral
> >> content, such as compiled binaries of the most recent release.
> >> '''
> >>
> >> The phrase "ephemeral content" is a bit disconcerting. It suggests
> >> values and attitudes towards this data which will probably be reflected
> >> in the requirements, specification, and implementation of the software.
> >>
> >> In the use-case I have in mind, this data would be "immutable content"
> >> and should be considered precious.
> >
> > That's not, as i understand it, the intention of unversioned filed.
> > Anything "important" needs to be checked in (versioned). Unversioned
> > files are primarily intended for hosting pre-built binaries and such.
>
> We might not be intersecting on this point; a perspective difference, I
> suspect. What I am suggesting is that the current intention of
> unversioned files might need be slightly tweaked to encourage an
> additional use-case where the repository supports the organization and
> management of critical data (immutable; a snap-shot of reality; large
> binary files) in addition to highly revised text files such as data
> analysis scripts, annotations, and documentation. Use of the unversioned
> files facility for storage and management of fleeting, intermediate
> files is also valuable. Quoting Chancellor Palpatine, I suggest we
> "embrace...a larger view" of unversioned files.
>
> On the other hand, it is still unclear [to me] if Fossil can be used
> this way. Once more complete unversioned files functionality is
> available, I can answer some of my questions through tests of the
> system. The critical points of interest are:
>
> 1. Maximum single unversioned file size.
> 2. Repository performance and integrity as overall size increases.
> 3. FuseFS performance.
> 4. Sync performance/reliability/usability.
>
> Once I have a better idea of these various characteristics and
> constraints, then it should be possible to estimate where Fossil might
> be a reasonable solution and where some other approach is needed.
>

I may not be understanding you, but from my point of view, it already does
what you want by supporting versioned files that you simply never change.
For example, you could have a repo that has a structure along the lines of:

/root/static-data/ -> a place to store lots of big binary blobs that you
don't intent to ever modify.

/root/dynamic-data/ -> a place to store things that you want to track the
history for

Is this inadequate? If so, how or why?

-- 
Scott Robison
___
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 files.

[Adam Jensen]

On 09/11/2016 01:54 PM, Stephan Beal wrote:
> On Sep 11, 2016 18:18, "Adam Jensen"  > wrote:
[snip]
>> '''
>> 5.4 Unversioned File Sync
>>
>> "Unversioned files" are files held in the repository where only the most
>> recent version of the file is kept rather than the entire change
>> history. Unversioned files are intended to be used to store ephemeral
>> content, such as compiled binaries of the most recent release.
>> '''
>>
>> The phrase "ephemeral content" is a bit disconcerting. It suggests
>> values and attitudes towards this data which will probably be reflected
>> in the requirements, specification, and implementation of the software.
>>
>> In the use-case I have in mind, this data would be "immutable content"
>> and should be considered precious.
> 
> That's not, as i understand it, the intention of unversioned filed.
> Anything "important" needs to be checked in (versioned). Unversioned
> files are primarily intended for hosting pre-built binaries and such.

We might not be intersecting on this point; a perspective difference, I
suspect. What I am suggesting is that the current intention of
unversioned files might need be slightly tweaked to encourage an
additional use-case where the repository supports the organization and
management of critical data (immutable; a snap-shot of reality; large
binary files) in addition to highly revised text files such as data
analysis scripts, annotations, and documentation. Use of the unversioned
files facility for storage and management of fleeting, intermediate
files is also valuable. Quoting Chancellor Palpatine, I suggest we
"embrace...a larger view" of unversioned files.

On the other hand, it is still unclear [to me] if Fossil can be used
this way. Once more complete unversioned files functionality is
available, I can answer some of my questions through tests of the
system. The critical points of interest are:

1. Maximum single unversioned file size.
2. Repository performance and integrity as overall size increases.
3. FuseFS performance.
4. Sync performance/reliability/usability.

Once I have a better idea of these various characteristics and
constraints, then it should be possible to estimate where Fossil might
be a reasonable solution and where some other approach is needed.

___
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 files.

[Stephan Beal]

On Sep 11, 2016 18:18, "Adam Jensen"  wrote:
>
> On 09/11/2016 05:41 AM, Stephan Beal wrote:
> > On Sep 10, 2016 19:31, "Adam Jensen"  > > wrote:
> >> 1. What is the largest size of any single file that can be checked into
> >> a repository?
> >
> > effectively limited by system memory: fossil needs approx. 2-3x the
> > file's size (concurrently in RAM) to create/apply deltas.
>
> Does it seem reasonable to assume that unversioned files will not have
> those (2-3x) memory requirements?

That seems reasonable but i have not yet used that feature nor know the
code (whereas i worked with the diff code a couple years ago).

>
> Also, do you suppose the *initial check-in* [of typical versioned files]
> involves that kind of memory usage (2-3x)?

Not as i recall, no.

Another memory cost comes to mind: the zip command creates zip files
in-memory, and may choke on huge repos/files.

>
> >> 2. How well will the sync command handle large files?
> >
> > it syncs whole blobs at a time, which are normally (for most versions of
> > a file after the first) highly efficient/tiny deltas.
>
> If a blob is ~1GB, will the data transfer mechanism hang in there and
> get the job done? I found this page:
>
> https://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki

It should always keep going until success or an unrecoverable error.

>
> which might answer my question after I digest it all (probably requiring
> some research (I'm not a Computer Scientist or Software Engineer)).
>
> But there was something, somewhat unrelated, on that page that did stand
> out. It says:
>
> '''
> 5.4 Unversioned File Sync
>
> "Unversioned files" are files held in the repository where only the most
> recent version of the file is kept rather than the entire change
> history. Unversioned files are intended to be used to store ephemeral
> content, such as compiled binaries of the most recent release.
> '''
>
> The phrase "ephemeral content" is a bit disconcerting. It suggests
> values and attitudes towards this data which will probably be reflected
> in the requirements, specification, and implementation of the software.
>
> In the use-case I have in mind, this data would be "immutable content"
> and should be considered precious.

That's not, as i understand it, the intention of unversioned filed.
Anything "important" needs to be checked in (versioned). Unversioned files
are primarily intended for hosting pre-built binaries and such.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
___
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 files.

[Adam Jensen]

On 09/11/2016 05:41 AM, Stephan Beal wrote:
> On Sep 10, 2016 19:31, "Adam Jensen"  > wrote:
>> 1. What is the largest size of any single file that can be checked into
>> a repository?
>
> effectively limited by system memory: fossil needs approx. 2-3x the
> file's size (concurrently in RAM) to create/apply deltas.

Does it seem reasonable to assume that unversioned files will not have
those (2-3x) memory requirements?

Also, do you suppose the *initial check-in* [of typical versioned files]
involves that kind of memory usage (2-3x)?

>> 2. How well will the sync command handle large files?
> 
> it syncs whole blobs at a time, which are normally (for most versions of
> a file after the first) highly efficient/tiny deltas.

If a blob is ~1GB, will the data transfer mechanism hang in there and
get the job done? I found this page:

https://www.fossil-scm.org/fossil/doc/trunk/www/sync.wiki

which might answer my question after I digest it all (probably requiring
some research (I'm not a Computer Scientist or Software Engineer)).

But there was something, somewhat unrelated, on that page that did stand
out. It says:

'''
5.4 Unversioned File Sync

"Unversioned files" are files held in the repository where only the most
recent version of the file is kept rather than the entire change
history. Unversioned files are intended to be used to store ephemeral
content, such as compiled binaries of the most recent release.
'''

The phrase "ephemeral content" is a bit disconcerting. It suggests
values and attitudes towards this data which will probably be reflected
in the requirements, specification, and implementation of the software.

In the use-case I have in mind, this data would be "immutable content"
and should be considered precious. The goals would be to avoid
accidental loss and/or corruption. It isn't a low-value, fleeting
scratch-pad that would be thrown away on a regular basis.

Perspective makes a difference in what gets built into a system, and how
it gets built...
___
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 files.

[Stephan Beal]

On Sep 10, 2016 19:31, "Adam Jensen"  wrote:
> 1. What is the largest size of any single file that can be checked into
> a repository?

effectively limited by system memory: fossil needs approx. 2-3x the file's
size (concurrently in RAM) to create/apply deltas.

> 2. How well will the sync command handle large files?

it syncs whole blobs at a time, which are normally (for most versions of a
file after the first) highly efficient/tiny deltas.

- stephan beal
Written on an embedded device. Please pardon brevity and auto-correction.
___
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 files.

[Adam Jensen]

On 09/10/2016 01:31 PM, Adam Jensen wrote:
[snip]
> 1. What is the largest size of any single file that can be checked into
> a repository?
[snip]

I did some tests with Fossil trunk, checked-out and compiled today.

too big: dd if=/dev/urandom of=1GB-file.test bs=64M count=16
too big: dd if=/dev/urandom of=64Mx15-file.test bs=64M count=15
*works*: dd if=/dev/urandom of=64Mx14-file.test bs=64M count=14

answer: somewhere between 939524096 and 1006632960 bytes
___
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 files.

[Adam Jensen]

On 09/09/2016 10:20 PM, Richard Hipp wrote:
> On 9/9/16, Adam Jensen  wrote:
>> On 09/05/2016 05:23 PM, Adam Jensen wrote:
>>> B. I suspect the storage requirement will be twice (2x) the data size -
>>> the data is stored once in the Fossil database and another copy would
>>> exist in the file-system [as a check-out].
>>
>> I wonder if it would be nifty if Fossil could export a set (or several
>> sets) of files as a FUSE[1] file-system?
> 
> Already does that. https://www.fossil-scm.org/fossil/help?cmd=fusefs
> 

That's awesome! It might be possible that with only a few tweaks in a
few commands that Fossil could be used effectively and smoothly to work
with large unversioned data/media files.

In my ongoing attempt to better understand the capabilities and
constraints of how Fossil might be used to manage large datasets along
with their analysis methods and products, I have two additional questions:

1. What is the largest size of any single file that can be checked into
a repository?

2. How well will the sync command handle large files?

Additionally, and this might not be a reasonable variation of the fusefs
command, I've only been playing with it for about ten minutes, but it
might be easier to understand and use if there were a couple more options:

Usage: fossil fusefs ?options? DIRECTORY

Options:

--debug

-R|--repository REPO*new* There need not be an existing checkout.

?VERSION | --latest?*new*

This command uses the Fuse Filesystem (FuseFS) to mount a *READ-ONLY*
directory at DIRECTORY that contains the content of all check-ins in the
repository.

If ?VERSION is specified, the names of files are DIRECTORY/PATH where
DIRECTORY is the root of the mount, and PATH is the pathname of the file
in the check-in.

If not ?VERSION is not specified, the names of files are
DIRECTORY/checkins/VERSION/PATH where DIRECTORY is the root of the mount
and VERSION is any valid check-in name (examples: "trunk" or "tip" or a
tag or any unique prefix of a SHA1 hash, etc).

___
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 files.

[Richard Hipp]

On 9/9/16, Adam Jensen  wrote:
> On 09/05/2016 05:23 PM, Adam Jensen wrote:
>> B. I suspect the storage requirement will be twice (2x) the data size -
>> the data is stored once in the Fossil database and another copy would
>> exist in the file-system [as a check-out].
>
> I wonder if it would be nifty if Fossil could export a set (or several
> sets) of files as a FUSE[1] file-system?

Already does that. https://www.fossil-scm.org/fossil/help?cmd=fusefs

-- 
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] Unversioned files.

[Adam Jensen]

On 09/05/2016 05:23 PM, Adam Jensen wrote:
> B. I suspect the storage requirement will be twice (2x) the data size -
> the data is stored once in the Fossil database and another copy would
> exist in the file-system [as a check-out].

I wonder if it would be nifty if Fossil could export a set (or several
sets) of files as a FUSE[1] file-system? How well would that enable the
case were one might want to arrange their files in various ways
(branches(?)) and present [subsets of] the files as various "views"
without increasing the storage requirements [significantly] (no
duplication of the large files)?

[1]: https://github.com/libfuse/libfuse
___
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 files.

[Adam Jensen]

On 09/05/2016 03:00 AM, Gour wrote:
[snip]
> Now, when I got rid of ownCloud and replaced it with something lighter
> to sync my calendars/contacts with the phone, I plan to manually cp-ing
> media files to my computer and considering to put all those
> photos/videos as unversioned files in a Fossil repo.
> 
> I use 64bit Linux (Debian Sid) with XFS filesystem, so wonder if there
> are any recommended limit in regard to number of files kep in the repo
> and/or size of the Fossil repo?

I'm not a software developer so my technical insight into these issues
might be dangerously insufficient in some places but a couple of data
points gleaned from the web might be relevant to the discussion. (bottom
of the page)

The two issues that stand out [to me] are:

A. The Fossil repository might have a maximum size for any single
[check-in] file of around 1 or 2 GB ([2] "Maximum length of a string or
BLOB").

B. I suspect the storage requirement will be twice (2x) the data size -
the data is stored once in the Fossil database and another copy would
exist in the file-system [as a check-out].

In a situation where many large files are being managed, those two
issues might become significant.

I can imagine broad classes of applications within various scientific
endeavors where there could be easily ~5TB of instrumentation data in
~10,000 files. Current technology makes this very cost effective.

While the measurement data would probably need to be considered
immutable, the file metadata, annotations, analysis scripts, commentary,
discussion, issues, etc. would probably undergo heavy edits/revisions.
(It would be valuable if there were audit trails within the file
management/data-sharing system (i.e., file integrity checks with
chain-of-custody-like verification)).

Fossil almost does everything that is needed to become a killer app for
people who need a consolidated [and comprehensible] method/tool to
manage, share, and collaborate around a common data-set (e.g., research
groups in university laboratories).

There are a couple of other capabilities that would extend the
use-case/user-base even further but I suspect I am already too far off
the reservation for general toleration.


[1]:
http://xfs.org/docs/xfsdocs-xml-dev/XFS_User_Guide/tmp/en-US/html/ch02s04.html
--
2.4. XFS Limits
32 bit Linux

Maximum File Size = 16TB (O_LARGEFILE)
Maximum Filesystem Size = 16TB

64 bit Linux

Maximum File Size = 9 Million TB = 9 ExaB
Maximum Filesystem Size = 18 Million TB = 18 ExaB
--


And [2]: https://sqlite.org/limits.html
--
Maximum length of a string or BLOB

The maximum number of bytes in a string or BLOB in SQLite is defined by
the preprocessor macro SQLITE_MAX_LENGTH. The default value of this
macro is 1 billion (1 thousand million or 1,000,000,000). You can raise
or lower this value at compile-time using a command-line option like this:

-DSQLITE_MAX_LENGTH=123456789

The current implementation will only support a string or BLOB length up
to 231-1 or 2147483647. And some built-in functions such as hex() might
fail well before that point. In security-sensitive applications it is
best not to try to increase the maximum string and blob length. In fact,
you might do well to lower the maximum string and blob length to
something more in the range of a few million if that is possible.
--

___
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 files.

[Gour]

On Fri, 2 Sep 2016 13:05:43 -0400
Richard Hipp  wrote:

> At the moment, unversioned files are not part of the check-out.  So
> this is a feature.

OK. Thank you.

Now, when I got rid of ownCloud and replaced it with something lighter
to sync my calendars/contacts with the phone, I plan to manually cp-ing
media files to my computer and considering to put all those
photos/videos as unversioned files in a Fossil repo.

I use 64bit Linux (Debian Sid) with XFS filesystem, so wonder if there
are any recommended limit in regard to number of files kep in the repo
and/or size of the Fossil repo?


Sincerely,
Gour

-- 
It is far better to discharge one's prescribed duties, even though
faultily, than another's duties perfectly. Destruction in the course
of performing one's own duty is better than engaging in another's
duties, for to follow another's path is dangerous.


___
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 files.

[Richie Adler]

Adam Jensen decía, en el mensaje "Re: [fossil-users] Unversioned files." del
3/9/2016 09:27:05:

> a next step might be to track,
> manage, and share items in the file-system that are not actually stored
> in the repository database file; an example might be media files or HDF5
> dataset files.

-1

> And not to be too overwhelmingly far out, but at this point one might
> begin to imagine that the sync function could be extended with
> torrent-like capabilities. (Too much?)

-inf




___
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 files.

[Adam Jensen]

On 09/02/2016 01:05 PM, Richard Hipp wrote:
[snip]
> I have the request to optionally include unversioned files in the
> check-out.  But that is not yet implemented.

Super cool. Not to hijack this thread but a next step might be to track,
manage, and share items in the file-system that are not actually stored
in the repository database file; an example might be media files or HDF5
dataset files.

In the example use-case of a media file repository, it could be that
Fossil is used to store annotation data such as subtitle files, edit
decision lists, playlists, etc. but it also tracks the origins of the
media files (which user added which file, when, etc.) and how those
media files might be sync'ed (obtain a local copy, omit a local copy,
share the local copy, etc.). The media files themselves would be
unversioned and stored in the traditional file-system.

And not to be too overwhelmingly far out, but at this point one might
begin to imagine that the sync function could be extended with
torrent-like capabilities. (Too much?)

___
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 files.

[Richard Hipp]

On 9/2/16, Gour  wrote:
> On Tue, 30 Aug 2016 14:31:06 -0400
> Richard Hipp  wrote:
>
>> Your feedback on this new feature is appreciated.
>
> I've added one whole directory with several subfolders (via shell
> scripting) and an see them with 'fossil unver ls'.
>
> However, the same set of files is also listed as output of 'fossil
> extras'. Is it afeature that one has to explicitly ignore them not to be
> shown with 'extras' or do I miss something?

At the moment, unversioned files are not part of the check-out.  So
this is a feature.

I have the request to optionally include unversioned files in the
check-out.  But that is not yet implemented.
-- 
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] Unversioned files.

[Gour]

On Tue, 30 Aug 2016 14:31:06 -0400
Richard Hipp  wrote:

> Your feedback on this new feature is appreciated.

I've added one whole directory with several subfolders (via shell
scripting) and an see them with 'fossil unver ls'.

However, the same set of files is also listed as output of 'fossil
extras'. Is it afeature that one has to explicitly ignore them not to be
shown with 'extras' or do I miss something?


Sincerely,
Gour

-- 
The senses are so strong and impetuous, O Arjuna,
that they forcibly carry away the mind even of a man
of discrimination who is endeavoring to control them.


___
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 files.

[Gour]

On Tue, 30 Aug 2016 14:31:06 -0400
Richard Hipp  wrote:

> Your feedback on this new feature is appreciated.

What about ability to add the whole directory containing unversioned
files? I used (fish)shell scripting to do it, but still...


Sincerely,
Gour

-- 
A person who is not disturbed by the incessant flow of
desires — that enter like rivers into the ocean, which is
ever being filled but is always still — can alone achieve
peace, and not the man who strives to satisfy such desires.


___
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 files.

[Taras Zakharko]

My use case is similar to what Adam describes. I already wrote a mail about 
this some time ago, but as I was absent last month, I couldn’t look at this 
feature in more detail until now. To reiterate, we use Fossil for collaborative 
paper writing. There are a lot of supplementary data that is useful to have 
around in the repository, but which does not need to be versioned (reports, 
current datasets etc.). It would be very useful to us if we had the ability to 
make unversioned files part of the checkout as a per-project option. 

@Richard (or others), how would you estimate the difficulty of adding this 
functionality? If I understand correctly, one would need to add a new field for 
storing the path of the unversioned file as well as logic that writes these 
files on checkout. I assume that no changes would be needed for the sync 
protocol itself? 

Best, 

 Taras



> On 31 Aug 2016, at 02:29, Adam Jensen  wrote:
> 
> On 08/30/2016 02:31 PM, Richard Hipp wrote:
>> A new feature of Fossil (currently unreleased and only available to
>> people who are willing to recompile the code on trunk) is "unversioned
>> files".
>> 
>>https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki
> 
> Hey, cool. This seems like a move in a good direction. I can imagine
> scenarios where some files are relevant to a project, and it would be
> convenient to bundle them into the Fossil database for backup and
> syncing, but saving the change history of those files doesn't really
> make much sense. For example, a project might have an associated SQLite
> database and it might be convenient to have a content .dump of that
> database and possibly a few Session Extension[1] changesets stored in
> the repository (and sync'able).
> 
> [1]: https://www.sqlite.org/sessionintro.html
> 
> In this case, it seems like the ability to check-in, check-out, and
> remove these unversioned files from the repository would be needed (for
> it to make sense). In an example work-flow, perhaps only the most recent
> database .dump would be kept. After a few chagesets are accumulated and
> a new common database state is agreed upon, a new .dump could be
> checked-in and the old dumps and chagesets could be removed (if they're
> no longer needed).
> 
> The current implementation doesn't look like it would support this
> (above) scenario.
> 
> "Unversioned files are not a part of a check-out. Unversioned files are
> intended to be accessible as web pages..."
> 
> ___
> 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 files.

[Adam Jensen]

On 08/30/2016 02:31 PM, Richard Hipp wrote:
> A new feature of Fossil (currently unreleased and only available to
> people who are willing to recompile the code on trunk) is "unversioned
> files".
> 
> https://www.fossil-scm.org/fossil/doc/trunk/www/unvers.wiki

Hey, cool. This seems like a move in a good direction. I can imagine
scenarios where some files are relevant to a project, and it would be
convenient to bundle them into the Fossil database for backup and
syncing, but saving the change history of those files doesn't really
make much sense. For example, a project might have an associated SQLite
database and it might be convenient to have a content .dump of that
database and possibly a few Session Extension[1] changesets stored in
the repository (and sync'able).

[1]: https://www.sqlite.org/sessionintro.html

In this case, it seems like the ability to check-in, check-out, and
remove these unversioned files from the repository would be needed (for
it to make sense). In an example work-flow, perhaps only the most recent
database .dump would be kept. After a few chagesets are accumulated and
a new common database state is agreed upon, a new .dump could be
checked-in and the old dumps and chagesets could be removed (if they're
no longer needed).

The current implementation doesn't look like it would support this
(above) scenario.

"Unversioned files are not a part of a check-out. Unversioned files are
intended to be accessible as web pages..."

___
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 files.

[bch]

kamloops$ fossil unver revert
assertion "uvStatus==2" failed: file "./src/xfer.c", line 1893,
function "client_sync"
[1]   Abort trap (core dumped) fossil unver revert
kamloops$


On 8/30/16, bch  wrote:
> On 8/30/16, sky5w...@gmail.com  wrote:
>> This is a welcome addition to house nuisance files like bitmaps, icons,
>> etc.
>> But, I am confused by the in-out nomenclature?
>>
>> Push to remote: fossil unversioned sync
>> Pull from remote:   fossil unversioned revert
>> Checkout unv files: fossil unversioned export FILE  //1 at a time?
>>
>> If we have the prefix "fossil unversioned", why not allow Push and Pull
>> for
>> familiarity?
>
> My initial reaction is: "seconded".
>
>> And I'd prefer "fossil checkout" to have an unversioned switch to extract
>> unv files to disk instead of individual calls/file?
>>
>> Thanks for Fossil!
>>
>> On Tue, Aug 30, 2016 at 5:15 PM, Ross Berteig 
>> wrote:
>>
>>> On 8/30/2016 1:55 PM, Ron W wrote:
>>>
 Why only "sync -u" ?

>>>
>>> Probably to give an easy way to distinguish developer's clones from full
>>> mirrors. If the unversioned files are built releases, then I don't need
>>> them on my dev machine, so no reason to sync them.
>>>
>>> If unversioned files are used for something else, syncing them might
>>> make
>>> more sense.
>>>
>>> It might also make more sense for that to be controlled by a setting
>>> rather than a command line option to fossil sync. I'm not sure about
>>> that,
>>> without thinking through other use cases.
>>>
>>> On Tue, Aug 30, 2016 at 2:31 PM, Richard Hipp > wrote:

 A new feature of Fossil (currently unreleased and only available to
 people who are willing to recompile the code on trunk) is
 "unversioned
 files".
 

>>>
>>> --
>>> Ross Berteig   r...@cheshireeng.com
>>> Cheshire Engineering Corp.   http://www.CheshireEng.com/
>>> +1 626 303 1602
>>>
>>> ___
>>> 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 files.

[bch]

On 8/30/16, sky5w...@gmail.com  wrote:
> This is a welcome addition to house nuisance files like bitmaps, icons,
> etc.
> But, I am confused by the in-out nomenclature?
>
> Push to remote: fossil unversioned sync
> Pull from remote:   fossil unversioned revert
> Checkout unv files: fossil unversioned export FILE  //1 at a time?
>
> If we have the prefix "fossil unversioned", why not allow Push and Pull for
> familiarity?

My initial reaction is: "seconded".

> And I'd prefer "fossil checkout" to have an unversioned switch to extract
> unv files to disk instead of individual calls/file?
>
> Thanks for Fossil!
>
> On Tue, Aug 30, 2016 at 5:15 PM, Ross Berteig  wrote:
>
>> On 8/30/2016 1:55 PM, Ron W wrote:
>>
>>> Why only "sync -u" ?
>>>
>>
>> Probably to give an easy way to distinguish developer's clones from full
>> mirrors. If the unversioned files are built releases, then I don't need
>> them on my dev machine, so no reason to sync them.
>>
>> If unversioned files are used for something else, syncing them might make
>> more sense.
>>
>> It might also make more sense for that to be controlled by a setting
>> rather than a command line option to fossil sync. I'm not sure about
>> that,
>> without thinking through other use cases.
>>
>> On Tue, Aug 30, 2016 at 2:31 PM, Richard Hipp >> > wrote:
>>>
>>> A new feature of Fossil (currently unreleased and only available to
>>> people who are willing to recompile the code on trunk) is
>>> "unversioned
>>> files".
>>> 
>>>
>>
>> --
>> Ross Berteig   r...@cheshireeng.com
>> Cheshire Engineering Corp.   http://www.CheshireEng.com/
>> +1 626 303 1602
>>
>> ___
>> 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 files.

[sky5walk]

This is a welcome addition to house nuisance files like bitmaps, icons, etc.
But, I am confused by the in-out nomenclature?

Push to remote: fossil unversioned sync
Pull from remote:   fossil unversioned revert
Checkout unv files: fossil unversioned export FILE  //1 at a time?

If we have the prefix "fossil unversioned", why not allow Push and Pull for
familiarity?
And I'd prefer "fossil checkout" to have an unversioned switch to extract
unv files to disk instead of individual calls/file?

Thanks for Fossil!

On Tue, Aug 30, 2016 at 5:15 PM, Ross Berteig  wrote:

> On 8/30/2016 1:55 PM, Ron W wrote:
>
>> Why only "sync -u" ?
>>
>
> Probably to give an easy way to distinguish developer's clones from full
> mirrors. If the unversioned files are built releases, then I don't need
> them on my dev machine, so no reason to sync them.
>
> If unversioned files are used for something else, syncing them might make
> more sense.
>
> It might also make more sense for that to be controlled by a setting
> rather than a command line option to fossil sync. I'm not sure about that,
> without thinking through other use cases.
>
> On Tue, Aug 30, 2016 at 2:31 PM, Richard Hipp > > wrote:
>>
>> A new feature of Fossil (currently unreleased and only available to
>> people who are willing to recompile the code on trunk) is "unversioned
>> files".
>> 
>>
>
> --
> Ross Berteig   r...@cheshireeng.com
> Cheshire Engineering Corp.   http://www.CheshireEng.com/
> +1 626 303 1602
>
> ___
> 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