Re: [fossil-users] comparison with Git

[Konstantin Khomoutov]

On Thu, Sep 13, 2012 at 04:28:00PM -0700, Russ Paielli wrote:

> OK, so apparently I misunderstood in thinking that the "serverless,
> zero-administration" claim applies to Fossil. Thanks for the clarification.
> 
> If it were true, and if it distinguished Fossil from Git, I would have used
> it in my advocacy of Fossil.
I'd say that this aspect (tentative "zero-administration") would only
be of interest to persons who routinely perform the said administration
(possibly at their $dayjob), and users (in the sense "not system
administrators") are usually sold on other aspects of software.

> I am sold on the idea that Fossil is superior to Git on the basis of
> simplicity alone. Than again, I am currently a minimal Fossil user. Being
> an aero engineer rather than a developer per se, I'd rather not spend time
> learning Git. The problem, as I have said before here, is that Git seems to
> be the de facto standard for open-source software. So not knowing Git
> essentially shuts you out of most open source.
But as I understand, you're not a programmer (at least not a
"hard-core" type who just seek fun in learning the next big thing and
all that), so not learning Git to ride *this* wave looks to be perfectly
okay for you.

On the other hand, Git is not *that* hard to learn basic concepts,
really.  And it has external tools providing fancy GUIs, if needed.

> In addition, I feed slightly
> uncomfortable forcing someone who already knows Git to learn Fossil in
> order to work on my project. But maybe I shouldn't worry about that.
I think it highly depends on the person(s) you're considering as a
possible collaborator(s) for your project.  I'd say that learning Fossil
is not hard for anyone having decent knowledge of another DVCS system.
Another possible argument which might be used to convince someone is
that it's good to leave one's comfort zone from time to time; this
applies not only to social interactions but to programming languages and
software tools as well (and, I suppose, to many other fields I'm just
not familiar with).

You could also assess if your project would benefit from using
wiki/built-in documentation editor and issue tracker; if so, Fossil
might have a huge head start compared to other tools for you, and this
could be used when advocating its usage.

___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[David Given]

Richard Hipp wrote:
> You assume correctly.

Good to know --- just checking!

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Richard Hipp]

On Fri, Sep 14, 2012 at 1:29 AM, Scott Robison wrote:

> So I've spent some time writing a small and I think portable routine to
> detect if a buffer is a valid UTF-16 (either little or big endian). It
> rejects buffers if they contain an odd number of bytes or contain any of
> the 66 non-character code-points or have invalid surrogate usage. While
> this seems to work well on the handful of binary files I've tested it
> against, I'm curious as to whether it would be desired to additionally use
> some or all of the current binary file detection criteria? My thought being
> that a file could be perfectly valid UTF-16 but have an extremely long line
> or (worse in my opinion) embedded non-text characters (particularly U+
> or non-white-space control codes).


Detection of embedded non-printing characters, especially U+, would be
nice.

Should we insist on a BOM at the beginning of the file?


>
> SDR
>
>
> On Thu, Sep 13, 2012 at 6:07 PM, Richard Hipp  wrote:
>
>> You assume correctly.
>>
>> The use of iconv won't do, though, since everything also needs to work on
>> Unix.  There are small, portable conversion routines in SQLite that you can
>> copy.
>>
>> D. Richard Hipp - d...@sqlite.org
>> Sent from phone - pardon brevity
>>
>> On Sep 13, 2012 7:44 PM, "Scott Robison"  wrote:
>>
>> I assumed (dangerous though it may be) that "leaves anything that isn't
>> UTF-16 unchanged" meant "don't convert any buffer to UTF-8 if the
>> origination buffer is not UTF-16".
>>
>> SDR
>>
>> On Thu, Sep 13, 2012 at 5:04 PM, David Given  wrote:
>>
>>> >
>>> > On 13/09/12 21:08, Richard Hipp wrote:
>>> > [...]
>>> > > Basically, we need a routine that converts an...
>>>
>>> > ___
>>> > fossil-users mailing list
>>> > fossil-users@lists.f...
>>>
>>
>>
>> ___
>> 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 mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
>


-- 
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] comparison with Git

[Richard Hipp]

On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

>
> On the other hand, Git is not *that* hard to learn basic concepts,
> really.  And it has external tools providing fancy GUIs, if needed.
>

My argument goes like this:  Every developer has a fixed number of "brain
cycles" to use on any given day.  Some of this brain-energy must be
expended for overhead, such as finding ones way to the coffee machine, or
operating the version-control system (VCS).  The fewer brain-cycles one has
to spend on the overhead functions, the more there are available for us in
writing code.

The goal of Fossil is to require fewer brain-cycles.  Fossil isn't
perfect.  I'm sure there are things that can be done so that it requires
less effort.  But I believe it is better than monotone, bzr, or hg, and way
better than git.

Of all of the VCSes out there today, surely Git requires more daily
brain-cycles than any other.  I'm not talking about just the learning-curve
here.  Git requires more thought and attention even after you know it
well.  And that extra thought and attention that you devote toward
operating Git could be better spent working on your project.


-- 
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] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> 
> >
> > On the other hand, Git is not *that* hard to learn basic concepts,
> > really.  And it has external tools providing fancy GUIs, if needed.
> >
> 
> My argument goes like this:  Every developer has a fixed number of "brain
> cycles" to use on any given day.  Some of this brain-energy must be
> expended for overhead, such as finding ones way to the coffee machine, or
> operating the version-control system (VCS).  The fewer brain-cycles one has
> to spend on the overhead functions, the more there are available for us in
> writing code.
> 
> The goal of Fossil is to require fewer brain-cycles.  Fossil isn't
> perfect.  I'm sure there are things that can be done so that it requires
> less effort.  But I believe it is better than monotone, bzr, or hg, and way
> better than git.
> 
> Of all of the VCSes out there today, surely Git requires more daily
> brain-cycles than any other.  I'm not talking about just the learning-curve
> here.  Git requires more thought and attention even after you know it
> well.  And that extra thought and attention that you devote toward
> operating Git could be better spent working on your project.

Interesting idea, this of brain cycles. :)

I also find git particularly difficult. In the case of having two checkouts in
two computers, it ends up scaling to 4 heads: local and remote head in each
computer. And all operations (merge, fetch, ...) work updating references
between those *4* heads, instead of 2.

I find that with two checkouts, I shouldn't need graph operations between 4
heads. For me, it means double work.

Regards,
Lluís.
___
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] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
> flatw...@users.sourceforge.net> wrote:
> Of all of the VCSes out there today, surely Git requires more daily
> brain-cycles than any other.  I'm not talking about just the learning-curve
> here.  Git requires more thought and attention even after you know it
> well.  And that extra thought and attention that you devote toward
> operating Git could be better spent working on your project.

BTW, I've the impression that some people feel like they do something useful,
just because they do something. That's how I see that some people enjoy using
git. Like people who solves sudoku.

Nevertheless, there are some kind of projects where git or monotone can have an
advantage; for example, there is more fine grained control of what you share and
what not of your graph, into a remote repository.
___
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] comparison with Git

[Michal Suchanek]

Hello,

On 14 September 2012 14:43, Lluís Batlle i Rossell  wrote:
> On Fri, Sep 14, 2012 at 07:54:27AM -0400, Richard Hipp wrote:
>> On Fri, Sep 14, 2012 at 4:31 AM, Konstantin Khomoutov <
>> flatw...@users.sourceforge.net> wrote:
>> Of all of the VCSes out there today, surely Git requires more daily
>> brain-cycles than any other.  I'm not talking about just the learning-curve
>> here.  Git requires more thought and attention even after you know it
>> well.  And that extra thought and attention that you devote toward
>> operating Git could be better spent working on your project.
>
> BTW, I've the impression that some people feel like they do something useful,
> just because they do something. That's how I see that some people enjoy using
> git. Like people who solves sudoku.
>

I find that git and hg require more thought in different areas. I
don't use fossil much but I would lump it together with hg here due to
the stress on immutable history.

The thing to which promoters of immutable history are blind is that
while exact history record of development of particular feature might
be interesting and educational it is not the primary purpose if VCS.

For start the VCS history is necessarily imperfect record because you
have only certain points in time recorded - the commits. What happens
in between might be equally or even more interesting and educational
but is not seen in the record.

Second the purpose of VCS is not to record exact history to the
tiniest detail but to record change(set)s to the code that are
somewhat self-contained and can be understood on their own. This may
be so that you can later go back and see what you did or so that you
can take these changesets and send them to an upstream/peer developer
for review, and it makes sense to them.

And the makes *sense* is the crucial part here. When you learn maths
you often hear something like this theorem AB was first proven by XY
using method CD but we will today prove it using a much shorter and
easier to understand method EF. Similarly, when implementing a feature
into a piece of software the real history and the logical changes that
make sense and are easy to review are often quite different things.

With git you get powerful history rewriting commands. The drawback is
that you have to be careful to not lose anything important in the
rewriting.

With hg and fossil rewriting is hard to non-existent and you end up
with a jungle of commits that is hard to navigate and without tools to
adequately manage such jungle.

So for me the cycles for managing source with git and with hg/fossil
are spent in different places but I would not say that one requires
less than the other. The hg manual recommends to use one I/O
repository to which you pull from usptream and push finished features
and development repositories(s) that contain the jungle of unfinished
features that you can just blow away when the feature is finished. Git
allows managing that in one repo but you need to remember doing
backups before attempting any drastic surgery on it. Not that you
don't need backups for other reasons, anyway.

Thanks

Michal
___
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] comparison with Git

[Richard Hipp]

On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek  wrote:

>
> The thing to which promoters of immutable history are blind is that
> while exact history record of development of particular feature might
> be interesting and educational it is not the primary purpose if VCS.
>

The exact preservation of history is considered "best practice" for
high-reliability and safety-critical systems.  Fossil, for example, was
designed to meet the VCS requirements of DO-178B level A.  (Ref:
http://en.wikipedia.org/wiki/DO-178B)

You might not think that exact preservation of history is one of the
primary purposes of VCS, but not every project manager thinks exactly like
you.

-- 
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] comparison with Git

[Mike Meyer]

On Fri, Sep 14, 2012 at 8:35 AM, Michal Suchanek  wrote:
> The thing to which promoters of immutable history are blind is that
> while exact history record of development of particular feature might
> be interesting and educational it is not the primary purpose if VCS.

That depends on what you're using the VCS for. Given that I use the
VCS to capture an exact history of the change sets I thought were
worth committing, that *is* it's primary purpose.

> And the makes *sense* is the crucial part here. When you learn maths
> you often hear something like this theorem AB was first proven by XY
> using method CD but we will today prove it using a much shorter and
> easier to understand method EF. Similarly, when implementing a feature
> into a piece of software the real history and the logical changes that
> make sense and are easy to review are often quite different things.

True. And which of the two things you are interested in will depend on
*why* you're using the VCS. For me, the *real* history is the
important thing. Yeah, I may record having done something the wrong
way, but having a record of the wrong way and the results of doing it
that way is *also* important. Others can either skip doing that
exploration, or look through the history to see *why* that way is
wrong.

> With git you get powerful history rewriting commands. The drawback is
> that you have to be careful to not lose anything important in the
> rewriting.

Your view matches the common view of git users, which follow the Linux
project and treat the repository as part of the public face of the
project. If you look at things that way, not being able to edit the
repository history makes about as much sense as not being able to edit
the web site. I see the VCS as part of the internal project
documentation. Being allowed to edit it makes as much sense as editing
generated API documentation to change function signatures.

http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] comparison with Git

[Michal Suchanek]

On 14 September 2012 15:52, Richard Hipp  wrote:
>
>
> On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek  wrote:
>>
>>
>> The thing to which promoters of immutable history are blind is that
>> while exact history record of development of particular feature might
>> be interesting and educational it is not the primary purpose if VCS.
>
>
> The exact preservation of history is considered "best practice" for
> high-reliability and safety-critical systems.  Fossil, for example, was
> designed to meet the VCS requirements of DO-178B level A.  (Ref:
> http://en.wikipedia.org/wiki/DO-178B)
>
> You might not think that exact preservation of history is one of the primary
> purposes of VCS, but not every project manager thinks exactly like you.
>

I don't think that's a bad goal. The failure I see is inadequate tools
for working with the resulting commit jungle. And if you were really
obstinate about that then fossil fails in that it does not record
*every* change, it requires explicit commits.

Thanks

Michal
___
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] comparison with Git

[Jacek Cała]

Hi all,

My two cents:

I like phrase *commit jungle* and sometimes would like to revert some
commits or "re-commit" things a bit different. I also suppose that it
is not that rare when people commit something by mistake or something
which has not been tested enough. On the other hand my gut feeling is
that (apart from what was said before) changing history is just bad
and should be avoided.

Perhaps the tooling you are talking about is just a filtered commit
view. I mean if fossil allowed users to attach a tag (e.g. "private")
to commits to say that they aren't visible in the timeline by default,
we could avoid the jungle and also keep exact history by giving users
a "full view" option where everything is visible (as it is shown
currently).

Also the thing is that some commits tend to be more important than
others (you usually tag somehow like version X.Y). But in this context
it's perhaps better to say that some commits are much less important
than others (e.g. correcting a spelling mistake in the comments). I
think that the filtered view would allow to hide these.

Michal would that be enough for you to match with the git rewriting
option (which I'm not aware of)?

  Cheers,
  Jacek


2012/9/14 Michal Suchanek :
> On 14 September 2012 15:52, Richard Hipp  wrote:
>>
>>
>> On Fri, Sep 14, 2012 at 9:35 AM, Michal Suchanek  wrote:
>>>
>>>
>>> The thing to which promoters of immutable history are blind is that
>>> while exact history record of development of particular feature might
>>> be interesting and educational it is not the primary purpose if VCS.
>>
>>
>> The exact preservation of history is considered "best practice" for
>> high-reliability and safety-critical systems.  Fossil, for example, was
>> designed to meet the VCS requirements of DO-178B level A.  (Ref:
>> http://en.wikipedia.org/wiki/DO-178B)
>>
>> You might not think that exact preservation of history is one of the primary
>> purposes of VCS, but not every project manager thinks exactly like you.
>>
>
> I don't think that's a bad goal. The failure I see is inadequate tools
> for working with the resulting commit jungle. And if you were really
> obstinate about that then fossil fails in that it does not record
> *every* change, it requires explicit commits.
>
> Thanks
>
> Michal
> ___
> 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] comparison with Git

[Michal Suchanek]

On 14 September 2012 16:57, Jacek Cała  wrote:
> Hi all,
>
> My two cents:
>
> I like phrase *commit jungle* and sometimes would like to revert some
> commits or "re-commit" things a bit different. I also suppose that it
> is not that rare when people commit something by mistake or something
> which has not been tested enough. On the other hand my gut feeling is
> that (apart from what was said before) changing history is just bad
> and should be avoided.

The commit jungle the result of exactly that - reverting  some commits
or recommitting with the old commits staying around in many short
stumped branches.

>
> Perhaps the tooling you are talking about is just a filtered commit
> view. I mean if fossil allowed users to attach a tag (e.g. "private")
> to commits to say that they aren't visible in the timeline by default,
> we could avoid the jungle and also keep exact history by giving users
> a "full view" option where everything is visible (as it is shown
> currently).
>
> Also the thing is that some commits tend to be more important than
> others (you usually tag somehow like version X.Y). But in this context
> it's perhaps better to say that some commits are much less important
> than others (e.g. correcting a spelling mistake in the comments). I
> think that the filtered view would allow to hide these.
>
> Michal would that be enough for you to match with the git rewriting
> option (which I'm not aware of)?

Indeed, it's about good  tools for filtering out unwanted commits and
good tutorial for using those tools. Not only for viewing but also for
pushing/pulling. Or perhaps good view filters would make pushing lots
of junk less of an issue.

Thanks

Michal
___
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] comparison with Git

[Lluís Batlle i Rossell]

On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
> On 14 September 2012 16:57, Jacek Cała  wrote:
> > Hi all,
> >
> > My two cents:
> >
> > I like phrase *commit jungle* and sometimes would like to revert some
> > commits or "re-commit" things a bit different. I also suppose that it
> > is not that rare when people commit something by mistake or something
> > which has not been tested enough. On the other hand my gut feeling is
> > that (apart from what was said before) changing history is just bad
> > and should be avoided.
> 
> The commit jungle the result of exactly that - reverting  some commits
> or recommitting with the old commits staying around in many short
> stumped branches.

I think that the git 'rebase' history rewriting could be stated different.
Maybe the graph could be altered with fossil cards, the same way commit logs are
changed. Then, "graph reworking" would not imply "history rewriting" (and thus
history loss) as git does.

Regards,
Lluís.
___
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] comparison with Git

[Remigiusz Modrzejewski]

On Sep 14, 2012, at 17:48 , Lluís Batlle i Rossell wrote:

> I think that the git 'rebase' history rewriting could be stated different.
> Maybe the graph could be altered with fossil cards, the same way commit logs 
> are
> changed. Then, "graph reworking" would not imply "history rewriting" (and thus
> history loss) as git does.

That's a nice idea. But I guess it would make things a lot more complicated...


Kind regards,
Remigiusz Modrzejewski



___
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] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 10:48 AM, Lluís Batlle i Rossell
wrote:

> On Fri, Sep 14, 2012 at 05:08:53PM +0200, Michal Suchanek wrote:
> > On 14 September 2012 16:57, Jacek Cała  wrote:
> > > Hi all,
> > >
> > > My two cents:
> > >
> > > I like phrase *commit jungle* and sometimes would like to revert some
> > > commits or "re-commit" things a bit different. I also suppose that it
> > > is not that rare when people commit something by mistake or something
> > > which has not been tested enough. On the other hand my gut feeling is
> > > that (apart from what was said before) changing history is just bad
> > > and should be avoided.
> >
> > The commit jungle the result of exactly that - reverting  some commits
> > or recommitting with the old commits staying around in many short
> > stumped branches.
>
> I think that the git 'rebase' history rewriting could be stated different.
> Maybe the graph could be altered with fossil cards, the same way commit
> logs are
> changed. Then, "graph reworking" would not imply "history rewriting" (and
> thus
> history loss) as git does.
>

Sure, you could have named, alternate timelines and just choose which one
to make the default, each timeline forming a namespace for its branches and
tags and timelines could inherit from other timelines.  That way you could
have rabasing without losing history.


Bill
___
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] comparison with Git

[Jacek Cała]

2012/9/14 Bill Burdick :
>
> Sure, you could have named, alternate timelines and just choose which one to
> make the default, each timeline forming a namespace for its branches and
> tags and timelines could inherit from other timelines.  That way you could
> have rabasing without losing history.
>

Hmmm... being pragmatic, who would like to have many timelines in the
same project? IMHO that would make things quite complicated or at
least unclear. Whereas the 'private' commit tags (which I mentioned
above) would make things easier I believe; easier to implement and
easier to use.

  Cheers,
  Jacek
___
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] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 11:00 AM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Sure, you could have named, alternate timelines and just choose which
> one to
> > make the default, each timeline forming a namespace for its branches and
> > tags and timelines could inherit from other timelines.  That way you
> could
> > have rabasing without losing history.
> >
>
> Hmmm... being pragmatic, who would like to have many timelines in the
> same project? IMHO that would make things quite complicated or at
> least unclear. Whereas the 'private' commit tags (which I mentioned
> above) would make things easier I believe; easier to implement and
> easier to use.
>

Private commit tags sound a little less versatile than Git rebasing.
 Multiple timelines is only one possibility, though.  You could do with
just 2, the "actual" and the "public."  The "public" could be a mutable
view on the "actual," which is immutable.  That brings up the question of
why there couldn't be more than just 2, of course  :).

Who would want to have that?  I think the Git community answers that.
 Anyone who wants to have a cleaner presentation of history than what
actually happened.  Being able to have a clean view without losing the
actual history sounds like a good trick, to me, and it would answer the
rebasing functionality gap that concerns some people.


Bill
___
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] comparison with Git

[Jacek Cała]

2012/9/14 Bill Burdick :
>
> Private commit tags sound a little less versatile than Git rebasing.


As said above, I don't really know how git rebasing works. Could you
shed more light on why it is more versatile than the simple private
tags?

  Cheers,
  Jacek
___
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] comparison with Git

[David Given]

Bill Burdick wrote:
[...]
> Who would want to have that?  I think the Git community answers that.
>  Anyone who wants to have a cleaner presentation of history than what
> actually happened.  Being able to have a clean view without losing the
> actual history sounds like a good trick, to me, and it would answer the
> rebasing functionality gap that concerns some people.

Would not the Fossil way to do this be to have two branches, one public
and one development, and have periodic merges across from the
development branch to the public branch? The public branch would have
the 'clean' history, with single checkins containing lots of files
representing complete features, but if anyone wants to see the details
they can follow the merge into the development branch and see how the
work was actually done.

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
___
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] comparison with Git

[Bill Burdick]

I'm not an expert on rebasing -- I've only done it a couple times, but as
far as I know, rebasing changes the timeline of a branch (potentially
radically).  It lets you reorder commits, combine them together (squash
them), and break them into multiple commits (edit them).  I've only done
interactive rebasing, which opens an editor with something like this in it
(taken from this article,
http://git-scm.com/book/en/Git-Tools-Rewriting-History ), listing the
commits you want to edit from oldest to newest:

pick f7f3f6d changed my name a bit
pick 310154e updated README formatting and added blame
pick a5f4a0d added cat-file

You then change the order of the lines and change whatever commands you
want from pick to edit or squash, save the file, and exit the editor,
allowing the rebase to continue.  Squash combines a commit with the one
before it.  Edit drops you to command line, where you can create multiple
commits and then returns you to the editor again with the new commits you
made inserted in the list.

Someone could certainly write a tool to do this in Fossil that creates a
new branch.


On Fri, Sep 14, 2012 at 11:12 AM, David Given  wrote:

> Bill Burdick wrote:
> [...]
> > Who would want to have that?  I think the Git community answers that.
> >  Anyone who wants to have a cleaner presentation of history than what
> > actually happened.  Being able to have a clean view without losing the
> > actual history sounds like a good trick, to me, and it would answer the
> > rebasing functionality gap that concerns some people.
>
> Would not the Fossil way to do this be to have two branches, one public
> and one development, and have periodic merges across from the
> development branch to the public branch? The public branch would have
> the 'clean' history, with single checkins containing lots of files
> representing complete features, but if anyone wants to see the details
> they can follow the merge into the development branch and see how the
> work was actually done.
>
___
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] comparison with Git

[Wes Freeman]

Rather than comparing Fossil to Git, I compare it to Github, the Git
hosting service I'm sure you're all aware of. They've come a long way
extending Git to make it easier to use and add the integrated issue
tracking/wiki that Fossil has that Git alone doesn't have. Github
additionally has some pretty nice looking Windows/Mac GUI desktop apps for
managing your local repositories, that automatically set up SSH keys, etc.,
and make the barrier to entry for Git trivial for those users (let's face
it, if you're a linux user, you should already know how to generate SSH
keys and do command line stuff, so I guess they didn't feel it was
necessary to provide a GUI so far).

The key difference between Github and Fossil, in my opinion, is that Github
is not open source and is quite expensive to use. I still use Fossil on
many personal projects, mostly because I run out of "private" repositories
on Github and am reluctant to increase my plan due to the monthly bill.
Github is a bit more shiny as a web application (I would hope so, given the
money they've got going in that they can spend on design/feature aspects).
Also, there's the fact that you typically provide your own hosting for
Fossil (although I know of the Chisel project--looks like that is coming
along as well; nice work James.), and the "forking" social aspect they sell
with.

One thing I like about Github that I wish Fossil had were email
notifications about things like commits and issues created/updated. I know
this was discussed years ago, and how it's difficult to set up because you
don't know which machine had the changes committed and who has already sent
emails out. But I imagine most people interested in this feature use Fossil
with a server hosting the "main" repository, so there should be a flag or
something you can send to fossil that would broadcast issue updates/code
commits, based on some configuration for an email server to send through.

As to the latest emails: The rebase commands come with many warnings about
how you shouldn't rewrite history except in your local copy, and people
have mixed opinions about that:
http://paul.stadig.name/2010/12/thou-shalt-not-lie-git-rebase-ammend.htmlThe
fact of the matter, though, is you can choose whether you want to use
that feature of git or not; you're certainly not forced to use it. I
somewhat prefer the autosyncing honest way that Fossil uses, but I can see
why some people would prefer to have one commit to look through while
merging changes in from someone, for example, which is the main use-case
for rebase, in my opinion.

Anyway, I don't mean to cause a heated discussion. Just throwing out some
more noise to this conversation, as one who uses both Fossil and Git on a
regular basis.

Wes

On Fri, Sep 14, 2012 at 12:00 PM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Sure, you could have named, alternate timelines and just choose which
> one to
> > make the default, each timeline forming a namespace for its branches and
> > tags and timelines could inherit from other timelines.  That way you
> could
> > have rabasing without losing history.
> >
>
> Hmmm... being pragmatic, who would like to have many timelines in the
> same project? IMHO that would make things quite complicated or at
> least unclear. Whereas the 'private' commit tags (which I mentioned
> above) would make things easier I believe; easier to implement and
> easier to use.
>
>   Cheers,
>   Jacek
> ___
> 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] comparison with Git

[Bill Burdick]

So, I think my description above shows why it's more versatile.  Rebasing
is a tool that reorders, combines, and splits commits.  A private tag might
be the end result of the editing.  Rebasing could be done in fossil, there
just isn't a tool to do it (and Git's rebase tools are pretty involved).
 You could produce a new branch/tag from it, instead of changing one and
that would be one way to rebase while preserving history.

Alternate timelines could also be a way to group tags/branches and bury the
ones that ended up not being important.


Bill


On Fri, Sep 14, 2012 at 11:11 AM, Jacek Cała  wrote:

> 2012/9/14 Bill Burdick :
> >
> > Private commit tags sound a little less versatile than Git rebasing.
>
>
> As said above, I don't really know how git rebasing works. Could you
> shed more light on why it is more versatile than the simple private
> tags?
>
>   Cheers,
>   Jacek
> ___
> 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] comparison with Git

[Mike Meyer]

Wes Freeman  wrote:
>The fact of the matter, though, is you can choose whether you want to use
>that feature of git or not; you're certainly not forced to use it.

Well, you can choose whether or not to use it locally. But once you share the 
repo, anyone you pull from can use it and force you to live with all the things 
that caused you to decide not to use it.
-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
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] comparison with Git

[Michal Suchanek]

On 14 September 2012 18:49, Mike Meyer  wrote:
>
>
> Wes Freeman  wrote:
>>The fact of the matter, though, is you can choose whether you want to use
>>that feature of git or not; you're certainly not forced to use it.
>
> Well, you can choose whether or not to use it locally. But once you share the 
> repo, anyone you pull from can use it and force you to live with all the 
> things that caused you to decide not to use it.

What people publish for you to pull depends on them, not the VCS.

Even VCS like fossil that does not have native history editing can be coerced.

What you pull from them is up to you when you do the pull.

Thanks

Michal
___
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] comparison with Git

[Jacek Cała]

Thanks Bill for the explanation.

I see private tags as the end result of 'squash' rather than 'edit'.
If you have three commits A-B-C and decide to hide B, you will see
A-C. And then diff between C-A will show combined commits B+C against
A.

Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
reordering as asking for troubles. I wonder if anyone uses it with
shared repos?
___
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] comparison with Git

[Bill Burdick]

Commit objects in Git are like manifests in Fossil, their id is the hash of
their contents, so "squash", "split", and "reorder" all end up creating new
commit objects with different ids.  After a rebase, brach points to the new
most-recent commit produced.  I'm pretty sure the old commit objects are
still around and will only disappear if they aren't part of some other
branch and you do a gc.

I think if you pull a rebased branch, you can get an error if the commit
your branch is no longer in the branch history, at which point you have to
decide what to do -- I think you can force the pull, if you want to.  If
you made changes on the branch, you'd probably have to tag and merge to get
it into the new version of the branch.


On Fri, Sep 14, 2012 at 12:03 PM, Jacek Cała  wrote:

> Thanks Bill for the explanation.
>
> I see private tags as the end result of 'squash' rather than 'edit'.
> If you have three commits A-B-C and decide to hide B, you will see
> A-C. And then diff between C-A will show combined commits B+C against
> A.
>
> Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
> reordering as asking for troubles. I wonder if anyone uses it with
> shared repos?
> ___
> 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] comparison with Git

[Mike Meyer]

Michal Suchanek  wrote:

>On 14 September 2012 18:49, Mike Meyer  wrote:
>> Wes Freeman  wrote:
>>>The fact of the matter, though, is you can choose whether you want to
>use
>>>that feature of git or not; you're certainly not forced to use it.
>> Well, you can choose whether or not to use it locally. But once you
>share the repo, anyone you pull from can use it and force you to live
>with all the things that caused you to decide not to use it.
>What you pull from them is up to you when you do the pull.

So you end up with two (or more) repos for the same project with different 
histories? And this is supposed to be better?

I think I'm better off choosing software designed to do the job I want done. 
Which in this case is to preserving history.

-- 
Sent from my Android tablet with K-9 Mail. Please excuse my swyping.
___
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] comparison with Git

[Michal Suchanek]

On 14 September 2012 19:03, Jacek Cała  wrote:
> Thanks Bill for the explanation.
>
> I see private tags as the end result of 'squash' rather than 'edit'.
> If you have three commits A-B-C and decide to hide B, you will see
> A-C. And then diff between C-A will show combined commits B+C against
> A.
>
> Regarding 'edit' and 'reorder', while 'edit' could be useful, I see
> reordering as asking for troubles. I wonder if anyone uses it with
> shared repos?

Rebase is often used to bring patches up to date so that they can be
efortlessly pulled upstream.

You see a repository that has commits

A-B-C

you clone it and write some changes

A-B-C-X-Y-Z

but upstream has changed

A-B-C-D-E-F

so you do a rebase so that your commits can be applied on top of F and
send then for review:

A-B-C-D-E-F-X'-Y'-Z'

If there are no conflicts between your changes and upstream this is
fine, otherwise you have to resolve them somehow, and upstream then
does not have to. They get nice linear history.

This leaves behind a hidden stump with the original X Y and Z commits
in git. In fossil the stump would remain and you would have to go out
of your way to hide it or not upload it during push.

Also if Z is really a fix for a bug in X which is not upstream yet you
might want to do an edit - swap Y and Z and squash X and Z so that the
upstream reviewer has easier job reviewing fewer patches.

A-B-C-D-E-F-X'Z'-Y'

Again, you are left with a stump branch.

As the stumps thicken you can get quite some jungle.

Some filtering to exclude those stumps would help a lot.

Thanks

Michal
___
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] comparison with Git

[David Given]

Bill Burdick wrote:
[...]
> I think if you pull a rebased branch, you can get an error if the commit
> your branch is no longer in the branch history, at which point you have to
> decide what to do -- I think you can force the pull, if you want to.  If
> you made changes on the branch, you'd probably have to tag and merge to get
> it into the new version of the branch.

I can tell you from experience that yes, you do get an error, but no, it
is not an informative one. What actually seems to happen is that your
upstream apparently conflicts with itself.

It took me about a week to sort this out, which I eventually did by
nuking the whole repository and starting again. Luckily I hadn't checked
anything into it.

(What, bitter? Me?)

-- 
┌─── ｄｇ＠ｃｏｗｌａｒｋ．ｃｏｍ ─ http://www.cowlark.com ─
│ "Parents let children ride bicycles on the street. But parents do not
│ allow children to hear vulgar words. Therefore we can deduce that
│ cursing is more dangerous than being hit by a car." --- Scott Adams
___
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] comparison with Git

[Jacek Cała]

2012/9/14 Michal Suchanek :
>
> so you do a rebase so that your commits can be applied on top of F and
> send then for review:
>
> A-B-C-D-E-F-X'-Y'-Z'
>
> If there are no conflicts between your changes and upstream this is
> fine, otherwise you have to resolve them somehow, and upstream then
> does not have to. They get nice linear history.

I don't understand. Without rebase you just merge the other branch
(D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts
and end up in the same point, ok with one more commit which is the
merge of F to Z.

> This leaves behind a hidden stump with the original X Y and Z commits
> in git. In fossil the stump would remain and you would have to go out
> of your way to hide it or not upload it during push.

Is a short branch in the timeline such a bad thing really?

> Also if Z is really a fix for a bug in X which is not upstream yet you
> might want to do an edit - swap Y and Z and squash X and Z so that the
> upstream reviewer has easier job reviewing fewer patches.
>
> A-B-C-D-E-F-X'Z'-Y'

That might be useful. But what if someone was tempted to do this for a
fix to a patch that was done 100 commits earlier... Might become
tricky I suppose.

  Cheers,
  Jacek
___
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] comparison with Git

[Michal Suchanek]

On 14 September 2012 20:10, Jacek Cała  wrote:
> 2012/9/14 Michal Suchanek :
>>
>> so you do a rebase so that your commits can be applied on top of F and
>> send then for review:
>>
>> A-B-C-D-E-F-X'-Y'-Z'
>>
>> If there are no conflicts between your changes and upstream this is
>> fine, otherwise you have to resolve them somehow, and upstream then
>> does not have to. They get nice linear history.
>
> I don't understand. Without rebase you just merge the other branch
> (D-E-F) to your cloned and updated repo (X-Y-Z), resolve any conflicts
> and end up in the same point, ok with one more commit which is the
> merge of F to Z.

Except with a merge of F-Z you get a single commit which is often huge
patch of no value on its own. To understand what it does you have to
review the whole branch before the merge possibly with numerous
intermediate merges. With rebase you get patches that become part of
single, linear history. You can pick only some patches from the start
and when there are no interdependencies even just patches from the end
or middle, even outside of VCS on top of unpacked release tarball.

>
>> This leaves behind a hidden stump with the original X Y and Z commits
>> in git. In fossil the stump would remain and you would have to go out
>> of your way to hide it or not upload it during push.
>
> Is a short branch in the timeline such a bad thing really?

It just makes following the development history more difficult.

And when it does not pass the review for the first time it's not going
to be just a simple short branch.

Especially if you merge, then fix some bugs in stuff before the merge
and add fixes as new commits, then merge again, and repeat a few
times. Spaghetti.

>
>> Also if Z is really a fix for a bug in X which is not upstream yet you
>> might want to do an edit - swap Y and Z and squash X and Z so that the
>> upstream reviewer has easier job reviewing fewer patches.
>>
>> A-B-C-D-E-F-X'Z'-Y'
>
> That might be useful. But what if someone was tempted to do this for a
> fix to a patch that was done 100 commits earlier... Might become
> tricky I suppose.

Of course, that's why there is a distinction between 'public' and
'private' branches. You should state when a commit is part of an
'official' history and should no longer be edited.

Thanks

Michal
___
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] comparison with Git

[Michael L. Barrow]

I'm a faithful Fossil user and I have enjoyed its "limitations" compared 
to Git because I consider them features. And pardon my commentary as I 
typically lurk on the list rather than provide ongoing input to the 
development.


If Git does all of this fancy stuff already, why not just use Git? Why 
must the beauty and simplicity of Fossil be 'polluted' with this 
additional baggage?


And, if you like some of what Fossil does and some of what Git does, 
then go and make a bastard stepchild of the two, but please do not 
advocate putting a bunch of "weird" stuff into Fossil!


*phew* I feel better now that I've said that...

:-)

--
michael at barrow dot me
+1.408.782.4249

___
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] comparison with Git

[Bill Burdick]

Rest assured that even if "weird" features like rebasing were to "pollute"
Fossil, no one would force you to use them :)


On Fri, Sep 14, 2012 at 1:42 PM, Michael L. Barrow wrote:

>
> I'm a faithful Fossil user and I have enjoyed its "limitations" compared
> to Git because I consider them features. And pardon my commentary as I
> typically lurk on the list rather than provide ongoing input to the
> development.
>
> If Git does all of this fancy stuff already, why not just use Git? Why
> must the beauty and simplicity of Fossil be 'polluted' with this additional
> baggage?
>
> And, if you like some of what Fossil does and some of what Git does, then
> go and make a bastard stepchild of the two, but please do not advocate
> putting a bunch of "weird" stuff into Fossil!
>
> *phew* I feel better now that I've said that...
>
> :-)
>
> --
> michael at barrow dot me
> +1.408.782.4249
>
>
> __**_
> 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] comparison with Git

[Michael L. Barrow]

On 9/14/12 11:53 AM, Bill Burdick wrote:
Rest assured that even if "weird" features like rebasing were to 
"pollute" Fossil, no one would force you to use them :)


But the size and complexity of the resulting application which is known 
for being well-engineered could suffer...


--
michael at barrow dot me
+1.408.782.4249

___
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] comparison with Git

[Bill Burdick]

On Fri, Sep 14, 2012 at 1:55 PM, Michael L. Barrow wrote:

> On 9/14/12 11:53 AM, Bill Burdick wrote:
>
>> Rest assured that even if "weird" features like rebasing were to
>> "pollute" Fossil, no one would force you to use them :)
>>
>>  But the size and complexity of the resulting application which is known
> for being well-engineered could suffer...


True for a generic, unknown feature, maybe, but not for rebasing, I think.
 Rebasing could be implemented without changing the codebase at all,
just using the fossil command in a script.  A lot of extensions could be
done as external scripts -- both Fossil and Git are very easy to extend,
that way.  They both have good architectures; Fossil's is SQL and Git's is
NoSQL :).


Bill
___
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 reason to have status and extras command at same time

[Dmitry Chuev]

Hello All,

I am newbie Fossil user and I wonder what is the reason to have two
different commands to show a checkout status: status and extras. In SCM
(Git, Svn) I have worked before there is single status command to show both
modified and new (i.e. not part of a checkout) files. Would not it be more
easier and "standard" to have just one single command to view status ?

Thank you for the explanation in advance.

--
Dmitry
___
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 reason to have status and extras command at same time

[Jan Danielsson]

On 09/15/12 00:17, Dmitry Chuev wrote:
> I am newbie Fossil user and I wonder what is the reason to have two
> different commands to show a checkout status: status and extras. In SCM
> (Git, Svn) I have worked before there is single status command to show both
> modified and new (i.e. not part of a checkout) files. Would not it be more
> easier and "standard" to have just one single command to view status ?
> 
> Thank you for the explanation in advance.

   I like that fossil status isn't cluttered. I regularly generate
source documentation using doxygen in my source tree, and "fossil
extras" just shows me all the gazillion files doxygen created.

   Try living with it for a while and see if you change your mind. I did.

-- 
Kind regards,
Jan Danielsson




signature.asc
Description: OpenPGP digital signature
___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Csaba Kos]

On Thu, Sep 13, 2012 at 2:08 PM, Richard Hipp wrote:

> It would be an interesting project to enhance Fossil so that it could
> support UTF16 in addition to UTF8.  What would be needed is an algorithm to
> detect when a file was UTF16.  (The BOM at the beginning of Kevin's example
> ought to be a big hint.)  Then automatically call a convert routine to
> generate UTF8 prior to passing the content into the diff logic, or into the
> wiki engine, or prior to display on the UTF8 webpage, etc.
> [...]

I think now would be a good time to discuss the possibility of a more generic
text conversion framework, i.e. not only UTF16 to UTF8 but also SHIFT-JIS
to UTF8, and so on. Also CR+NL to NL conversion could be handled by such
framework as well. One possibility is to support calling of an external command
which could be specified in some "...-glob" setting.

I'm not a git user, but as far as I know, git has a generic text
filtering framework that is capable of the above.

Regards,

Csaba

PS I'm a new list member, so I'll take this opportunity to briefly
introduce myself. I've been using fossil for a while and love
the integrated wiki and simplicity. I work in a multi-platform
environment (Linux, Win, Mac), so I bump into the EOL problem
every day. Because of that, I have started working on some EOL handling patches
for fossil, mostly to make my life easier. :) But it would be great to
have character encoding conversion support as well.

PS to Richard: contributor agreement should be arriving shortly!
___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

On Fri, Sep 14, 2012 at 5:46 AM, Richard Hipp  wrote:

>
> Detection of embedded non-printing characters, especially U+, would be
> nice.
>
> Should we insist on a BOM at the beginning of the file?
>

I don't think a BOM should be mandatory, as it is not required by Unicode.
Another thought:

Unicode characters have a General Category. The categories Letter, Mark,
Number, Punctuation, Symbol & Separator are obviously useful in the context
of Unicode encoded text files. That leaves the "Other" categories:

1. "Other, control": Some of these are useful in the context of text files
(tab, CR, LF, FF among others which are used to format text). Some not so
much. I'd think however fossil currently classifies such characters in
8-bit text is how they should be treated for Unicode.

2. "Other, format": I believe these should be included even though I think
they'd be rare in the types of files fossil would need to diff.

3. "Other, surrogate": If these appear in an invalid context in a document
it is not well formed UTF-16.

4. "Other, not assigned [Noncharacter]": If these appear anywhere in a
document it is not well formed UTF-16.

5. "Other, private use": Should we allow these in a file that fossil might
diff? Since they are private-use there is no 'standard' way of displaying
them, but people may legitimately want or need them in their private
documents.

6. "Other, not assigned [Reserved]": These are perfect valid code points,
and over time more of them will be allocated to other categories. We can
either allow them knowing they won't be displayable now but might be later
or restrict them until some future time. Either way the code has to be kept
up to date with future Unicode revisions, as a new code could be allocated
to a printable character or (theoretically) to a non-printable control code.

I'm assuming the desire for identifying UTF-16 and converting to UTF-8 is
*only* for the purposes of recognizing them as diffable text vs binary
files (though you might also want to use this to identify a file as Unicode
text vs 8-bit text vs binary when adding them to the repository). If the
first thought is correct, it would be possible to "expand" normally
non-printable characters into printable sequences in otherwise valid UTF-16
buffers. For example:

Let's say a line of text in a file has an embedded backspace character
(U+0008). We could say it is not a text file for that reason or we could
expand the normally non-printing backspace into literal text "U+0008". That
might be more valuable in the context of diffing files, and it causes no
harm in that the file as stored in the file system or the repository
remains unchanged.

Hopefully I'm not rambling and these thoughts are sufficiently coherent as
to make sense...

SDR
___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Scott Robison]

On Fri, Sep 14, 2012 at 8:20 PM, Csaba Kos  wrote:

> I think now would be a good time to discuss the possibility of a more
> generic
> text conversion framework, i.e. not only UTF16 to UTF8 but also SHIFT-JIS
> to UTF8, and so on. Also CR+NL to NL conversion could be handled by such
> framework as well. One possibility is to support calling of an external
> command
> which could be specified in some "...-glob" setting.
>
> I'm not a git user, but as far as I know, git has a generic text
> filtering framework that is capable of the above.
>

One thing I thought of yesterday but dismissed (and am now rethinking as a
result of your email) is maybe there should be a bit of meta-data that can
be attached to files to explicitly set their encoding. Having built in
detection code would still be useful to set it initially, and having it as
meta-data could make it possible for the user to change the encoding of the
file when fossil guessed wrong for whatever reason. A similar bit of
functionality could be provided for end of line handling. Regardless, I am
a fossil novice myself, so maybe that functionality is there and I am just
ignorant of it.

Regardless, having some basic UTF-16 to UTF-8 conversion built in is
helpful in advancing the goal of providing base functionality that is
available on all platforms without need to install or configure extra
tools. It would certainly be cool to provide some sort of hook to access
external tools that could handle transcoding from more encodings as needed.
Maybe options to build with ICU (much as SQLite provides) could provide
what you're describing for those that want it, and in the case that ICU is
not available, built in diffing is limited to those base supported
encodings...

SDR
___
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 enhancement idea. Was: trouble handling text files from SQL Server 2012

[Csaba Kos]

On Sat, Sep 15, 2012 at 1:21 PM, Scott Robison  wrote:
> One thing I thought of yesterday but dismissed (and am now rethinking as a
> result of your email) is maybe there should be a bit of meta-data that can
> be attached to files to explicitly set their encoding. Having built in
> detection code would still be useful to set it initially, and having it as
> meta-data could make it possible for the user to change the encoding of the
> file when fossil guessed wrong for whatever reason. A similar bit of
> functionality could be provided for end of line handling. Regardless, I am a
> fossil novice myself, so maybe that functionality is there and I am just
> ignorant of it.

I am a fossil novice myself, but I don't think there is such
functionality built-in currently.
There is the settings system, which is used for the "crnl-glob"
setting, for example, but it is not attached to individual files.
Also the settings are not versioned or synced (unless put into the
.fossil-settings folder).

My plan for the EOL conversion was to extend the syntax of the
"crnl-glob" setting in the following way:
*.txt:cr< force CR
*.txt:nl< force NL
*.txt:cr+nl   < force CR+NL
*.txt:native  < convert to native format
anything else: < allow CR+NL (current behaviour)

But I agree that properties attached to files (similarly to
subversion, perhaps) might be preferable for setting the encoding/line
ending.

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