On Sat, 01 Dec, Richard Hipp wrote:
> On Sat, Dec 1, 2012 at 4:02 AM, Stefan Bellon
> wrote:
>
> > That's the part I am interested in and I think this should go into
> > trunk.
>
> Added to trunk here: http://www.fossil-scm.org/fossil/info/647bb7b79f
Silly me, I just looked at the comment and n
2012/12/1 Stefan Bellon :
> sbellon@slim$ fossil status | egrep "(checkout|tags)"
> checkout: 99ab9fb47cfb20106564012b7678ca5d579060af 2012-12-01 04:49:38 UTC
> tags: trunk
> sbellon@slim$ grep "not contain any of these characters" src/file.c
> ** * Does not contain any of these ch
On Sat, Dec 1, 2012 at 4:02 AM, Stefan Bellon wrote:
> ** * Does not contain any of these characters in the path: "\*[]?"
>
> That's the part I am interested in and I think this should go into
> trunk.
>
Added to trunk here: http://www.fossil-scm.org/fossil/info/647bb7b79f
--
D. Richard
On Sat, 01 Dec, Jan Nijtmans wrote:
> I agree with Richard on this. The most important part of the patch is
> already on trunk now: allowing '[', ']', '"', '*' and '?' in
> filenames.
Really? That's the part I am interested in, but I do not see that
merged into trunk:
sbellon@slim$ fossil status
2012/12/1 Richard Hipp :
>> I would very much like to see this going into the upcoming 1.25
>> release. Is it scheduled to get merged back into trunk?
>
>
> No. This adds complication to a code base that is complicated enough
> already. It is vitally important to keep Fossil as simple as possible
On Fri, Nov 30, 2012 at 5:43 PM, Stefan Bellon wrote:
> On Tue, 27 Nov, Jan Nijtmans wrote:
>
> > This version allows all characters in filenames that
> > are permissible on UNIX, except '\'. And those files
> > can be checked out using Cygwin and Windows as
> > well, using Cygwin's solution: In
On Tue, 27 Nov, Jan Nijtmans wrote:
> This version allows all characters in filenames that
> are permissible on UNIX, except '\'. And those files
> can be checked out using Cygwin and Windows as
> well, using Cygwin's solution: In the file system
> translate those characters to 'safe' characters i
2012/11/25 Jan Nijtmans :
> New test version in [d3bee356ba]. It changes the
> "filename contains illegal characters" fatal into
> a warning, which should make your situation more
> managable: Even though files containing '\' still
> cannot be handled, they don't stop the
> "fossil addremove" anym
2012/11/22 Jan Nijtmans :
> 2012/11/22 Stefan Bellon :
>> On Thu, 22 Nov, Jan Nijtmans wrote:
>>
>>> Stefan, could you try out [e6a1910fa8]?
>>
>> This sounds very cool. :-)
New test version in [d3bee356ba]. It changes the
"filename contains illegal characters" fatal into
a warning, which should m
2012/11/22 Stefan Bellon :
> On Thu, 22 Nov, Jan Nijtmans wrote:
>
>> Stefan, could you try out [e6a1910fa8]?
>
> This sounds very cool. :-)
>
> However I still get:
>
> $ ~/tmp/fossil addremove
> [...]
> /home/bellonsn/tmp/fossil: filename contains illegal characters: str\i\ng.h
...
> Am I missing
On Thu, 22 Nov, Jan Nijtmans wrote:
> Stefan, could you try out [e6a1910fa8]?
This sounds very cool. :-)
However I still get:
$ ~/tmp/fossil addremove
[...]
/home/bellonsn/tmp/fossil: filename contains illegal characters: str\i\ng.h
This is with:
$ ~/tmp/fossil version
This is fossil version
2012/11/20 Richard Hipp :
> I think that there needs to be two separate versions of
> fossil_utf8_to_unicode(), or perhaps a parameter on one function, so that
> some strings can get the conversion of problematic characters to the unicode
> private-use range, while others go unaltered.
Done now in
On Tue, 20 Nov, Richard Hipp wrote:
> Some uses are less clear. For example, at
> http://www.fossil-scm.org/fossil/artifact/33d79f5b0a2?ln=850 we are
> converting an entire command-line, which does likely contain some
> filenames, but also might contain other text where *?"<>| are
> legitimate ch
2012/11/20 Richard Hipp :
> I think that there needs to be two separate versions of
> fossil_utf8_to_unicode(), or perhaps a parameter on one function, so that
> some strings can get the conversion of problematic characters to the unicode
> private-use range, while others go unaltered.
I guess you
On Tue, Nov 20, 2012 at 8:59 AM, Jan Nijtmans wrote:
> 2012/11/19 Stefan Bellon :
> > I think this restriction
> >
> > * Does not contain any of these characters in the path: "\*[]?"
> >
> > is too arbitrary. If you try to create a file or directory in the
> > Windows explorer and type e.g. a "
2012/11/19 Stefan Bellon :
> I think this restriction
>
> * Does not contain any of these characters in the path: "\*[]?"
>
> is too arbitrary. If you try to create a file or directory in the
> Windows explorer and type e.g. a " then you get a bubble help with the
> information that you must not
On Mon, 19 Nov, Richard Hipp wrote:
> I made the decision to disallow "problematic" characters in Fossil
> filenames 6 years ago. In theory, Fossil could allow these
> characters in filenames. But doing so would enhance the potential
> for bugs and would greatly complicate testing of the code.
On Mon, Nov 19, 2012 at 7:39 AM, Stefan Bellon wrote:
> On Mon, 19 Nov, Richard Hipp wrote:
>
> > The \ character is problematic because Windows cannot contain that
> > character in filenames (except as a separator between directory and
> > file names). If you were allowed to check this file int
2012/11/19 Stefan Bellon :
> This seems to me an inconsistency. Either support all allowed filenames
> per OS and skip them on OSes that cannot support them, or go with the
> set of filenames that all OSes can support (at least the mainstream
> ones).
>
> But being able to add str"i"ng.h but not st
On Mon, 19 Nov, Richard Hipp wrote:
> The \ character is problematic because Windows cannot contain that
> character in filenames (except as a separator between directory and
> file names). If you were allowed to check this file into Fossil,
> then the repository could not be checked out on Windo
On Mon, Nov 19, 2012 at 6:37 AM, Stefan Bellon wrote:
> Hi!
>
> On Mon, 19 Nov, Jan Nijtmans wrote:
>
> > This sounds like a bug in the SVN ->fossil converter, not
> > in fossil itself.
>
> Just to avoid any misunderstanding: I am not using any converter. I
> just did
>
> $ cd svn_working_copy
>
Hi!
On Mon, 19 Nov, Jan Nijtmans wrote:
> This sounds like a bug in the SVN ->fossil converter, not
> in fossil itself.
Just to avoid any misunderstanding: I am not using any converter. I
just did
$ cd svn_working_copy
$ fossil init myproject.fossil
$ fossil open --keep myproject.fossil
$ fossi
2012/11/19 Stefan Bellon :
> Now I was trying to convert an existing SVN repository to fossil and
> stumbled across this problem:
>
> ADDED str'i'ng.h
> ADDED str"i"ng.h
> ADDED str"ing.h
> fossil: filename contains illegal characters: str\i\ng.h
This sounds like a bug in the SVN ->fossil converte
Hi all,
first of all, let me say a big "thank you" for the Fossil SCM. I'm
already using it to store generated files during the build process in
order to retrieve them again later on for the various past builds.
Now I was trying to convert an existing SVN repository to fossil and
stumbled across
On 29 June 2010 05:31, Michael Richter wrote:
> On 29 June 2010 02:18, Eric wrote:
>>
>> [] are there for the same reason as * and ?:
>> ~ $ ls -d p[lu]*
>> play public_html
>
> Ah. I was unaware of that expansion. I always used something like p{l,u}*
> in those situations.
>
Why this choice?
On 29 June 2010 02:18, Eric wrote:
> [] are there for the same reason as * and ?:
>
> ~ $ ls -d p[lu]*
> play public_html
>
Ah. I was unaware of that expansion. I always used something like p{l,u}*
in those situations.
--
"Perhaps people don't believe this, but throughout all of the discuss
On 28 June 2010 at 3:26 pm, "Michael Richter" wrote:
> On 28 June 2010 21:20, Kevin Greiner wrote:
>
>> For a few files I see the following error:
>>fossil: filename contains illegal characters: prep_20100113[1] clean/
>> 135816_0001.ps
>>
>> I understand it's the square brackets that are caus
On 28 June 2010 21:20, Kevin Greiner wrote:
> For a few files I see the following error:
>fossil: filename contains illegal characters: prep_20100113[1] clean/
> 135816_0001.ps
>
> I understand it's the square brackets that are causing this error but not
> why this is by design. Could someone
This is perhaps a non-typical use case but I'm trying to take a daily
snapshot of a network share here at work. Thousands of files in thousands of
folders over which I don't have any control but for which I'd still like to
see a daily change history.
I'm using a command like this to get new files
29 matches
Mail list logo
