I'm not saying that it's necessarily a bug, but
it would be nice if during the VACUUM'ing phase of the
fossil rebuild a_huge.fossilrepository --vacuum --compress --cluster
the Fossil Web GUI would say that the repository is
currently being rebuilt in stead of saying
citation--start-
On 10/16/17 21:13, Warren Young wrote:
On Oct 16, 2017, at 7:28 PM, Andy Goth wrote:
I don't have the luxury of Cygwin because my end users won't have it.
You can just distribute the DLL, then.
The two programs that would need Cygwin are Fossil itself and my
application. My application is
On Oct 16, 2017, at 7:28 PM, Andy Goth wrote:
>
> I don't have the luxury of Cygwin because my end users won't have it.
You can just distribute the DLL, then.
In cases where your users *may* have Cygwin installed, it is considered polite
to install the DLL only when it doesn’t already exist on
On 10/16/2017 5:44 PM, Arseniy Terekhin wrote:
> I want to share my thought about symlinking in fossil.
>
> dir "my_empy_dir"
> dir "my_empy_dir2"
> ln "existing_file_in_repo" "new_link"
> ln_hard "existing_directory_in_repo" "new_hard_link"
> attr_executable "bin/*.sh"
> attr_hid
Warning: beware of back references in this email. Plan to read this
email twice. I guess I could have reorganized it, but I left Warren
Young's text in its original order.
On 10/16/2017 4:28 PM, Warren Young wrote:
> On Oct 14, 2017, at 4:16 PM, Andy Goth wrote:
>> Please review the enhanced-sy
On Oct 16, 2017, at 4:44 PM, Arseniy Terekhin wrote:
>
> What should "ln" do on FAT16/32 and exFAT filesystems? Well, I'd just expect
> fossil to not bother creating any links and maybe give a warning.
Or, write two copies of the file, then on checkin either: a) take the later of
the two files
I want to share my thought about symlinking in fossil.
I like that fossil manages files only and not other things like
directories*, permissions, symlinks and maybe ACLs. There is "empty-dirs"
setting and I'm okay with it, since it can be stored as file. And I think
all these things are OS specific
On Oct 14, 2017, at 4:16 PM, Andy Goth wrote:
>
> Please review the enhanced-symlink branch.
Aside from a manifest.symlinks file appearing at the project root, what should
we see? How do we test it?
For example, if I declare a file to be a symlink in the repository by editing
that file, what
On 10/16/17, Andy Goth wrote:
>
> I'd like to merge enhanced-symlink to trunk,
I'm not comfortable with that. My reasons are long and inarticulate.
I need to write them up, but i"m a little busy right now. For the
moment, let's just leave the symlink stuff on a branch.
--
D. Richard Hipp
d...@
On 10/14/2017 5:16 PM, Andy Goth wrote:
> Please review the enhanced-symlink branch. I can't test it properly
> this weekend because I don't have Windows anywhere at home.
Tested on Windows 7, works just the way my project needs it to work.
The manifest.symlinks file is created when the "l" flag
10 matches
Mail list logo
