Re: [fossil-users] problems with links in embedded documents

[Michal Suchanek]

On 23 November 2015 at 22:59, Ron W  wrote:
>
>
> On Mon, Nov 23, 2015 at 2:19 PM, Richard Hipp  wrote:
>>
>> That's all well and good, but Joerg is right - it would be convenient
>> to be able to specify the root of the repository in a hyperlink.  I've
>> pondered making that possible with some bit of magic like
>> "[$ROOT/wcontent]" or "".  But it seems
>> hackish.
>
>
> Why not use the  tag in the generated HTML?
>

Last time I tried using  it did not work out very well. Do you
have some idea what is browser support for this tag like? Especially
restricted and terminal-based browsers might be interesting.

More importantly, you might not know what the base is if you are
behind CGI. And the base might become invalid when you save the
generated HTML.

The most reliable thing would be to automagically generate enough ../
so the link points to the root of the repo, and the fossil service
knows what URL it was called by so it can generate those ../ just
fine. Anything else is asking for trouble imho.

This was my major grief with fossil web as well so I gave up on using
it since cross-linking between wiki and source becomes pretty much
impossible.

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] xkcd on git

[Michal Suchanek]

On 3 November 2015 at 22:31, Warren Young  wrote:
> On Nov 3, 2015, at 5:59 AM, Michal Suchanek  wrote:
>>

>>> Note that detached head state is impossible in Fossil and in most
>>> other VCSs.  (Unsure about Hg.)
>>
>> Detached head state is the state which you enter when you check out
>> some random commit id…Any VCS can do that.
>
> Nope:
>
> mkdir tmp
> cd tmp
> f clone http://fossil-scm.org ~/fossil.fossil
> f open ~/fossil.fossil
> f up 485aa80625acdb # some random commit ID
> echo '/* silly change */' >> src/shell.c
> f ci
>
> Result?  Error:
>
>would fork.  "update" first or use --allow-fork.
>
> So no, Fossil does not enter detached head state when you try to check in 
> something in the middle of a branch.
>
> If you follow Fossil’s recommendation (“update” first) your change is merged 
> into the tip of that branch, automatically if possible.  Then there is no 
> problem.
>
> If instead you force Fossil to accept the checkin with --allow-fork, you end 
> up with a dual-tipped branch, which doesn’t lose information, because the 
> forked branch is still attached to the rest of the Fossil tree.
>
> Alternately, you can check your changes in with --branch, which is 
> functionally the same as --allow-fork, except that the new branch has its own 
> name from the start, so you don’t end up with a dual-tipped branch, the very 
> thing Fossil is warning you about here.
>
> Furthermore, committing while in detached head state in Git does not create a 
> dual-tippped branch, as in Fossil.  It creates a free-floating branch, 
> disconnected from everything else.  If you then move to a named branch (e.g. 
> “git checkout master”) you *lose your work* because Git sees that you have 
> local changes that don’t refer to anything in the repo.
>
> Part of this gets back to drh’s earlier point about Git giving the developer 
> too much state to keep track of: it often happens because your local branch 
> set and the remote branch set aren’t the same.
>
> Fossil avoids that particular problem with autosync.  The only way I’ve ever 
> had a dual-tipped Fossil branch is because I was committing to a branch while 
> disconnected from the Internet, so Fossil couldn’t warn me that someone else 
> was moving that branch along at the same time, so when it came time to merge, 
> Fossil now had two different branches called foo, and needed manual help 
> fixing it.
>
> And let’s be clear: even in in the worst case above, the dual-tipped branch, 
> Fossil doesn’t lose information.  The only reason it’s even a problem is that 
> commands like “fossil up branch-name” are ambiguous while there are two 
> branches with that name.  As soon as someone heals the fork or gives the new 
> branch a unique name, there is no longer a problem.
>
>> It's completely fine to allow detached head state
>
> Fossil completely avoids it.  It is clearly not a necessary attribute of a 
> DVCS.


This is nice example of out of context quoting.

Also rephrasing what was left out of the quoted text is interesting
discussion technique.

When it comes to this I guess it's time to close the topic.

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] xkcd on git

[Michal Suchanek]

On 2 November 2015 at 18:20, Scott Robison  wrote:

>
> Given that the git cli interface was the only interface for humans from the
> start, I dare say it was meant for humans.
>

Any git reference I have seen has that notion of 'porcelain' and
'plumbing' with plumbing being the internals and porcelain being the
interface for the user. To perform everyday tasks with git you will
need some of the 'plumbing' commands because the 'porcelain' part just
never happened/was finished.

So yes, there is some issue here.

What we are left with is the plumbing without the sink and it *does*
stink when you get anywhere near it unless you go out of your way to
make that U-shape with plain pipes.

On 2 November 2015 at 20:40, Richard Hipp  wrote:
> On 11/2/15, Michal Suchanek  wrote:
>>
>> when you
>> want to separate the changes you want to commit and changes you want
>> to ... keep uncommitted to do more work on them this is quite
>> useful. And don't tell me nobody ever mixes unrelated and possibly
>> conflicting changes in the same working directory.
>
> People do that.  But it is much more easily accomplished by simply
> listing the files you want to commit on the "commit" command line.
> That's what every other VCS in the world other than Git does.  And it
> works great.  And it does not require the added confusion of a staging
> area.

Unless you have unrelated changes in the same file, of course.

>
> But on the other hand, you should not be checking-in untested changes.
> The proper way to do incremental check-ins is to stash the whole lot,
> then pull out individual pieces from the stash and test and commit
> them separately.

And that's what the staging area allows for easily. You add and remove
hunks from staging area until you like the split and commit the
staging area at which point CI fires or you stash the remaining
changes and run your tests. Or you just don't care, of course.

Also note that when using a frontend the staging area is something the
frontend can present to the user and it's unlikely to change until the
user acks the commit, unlike the files in the working directory.

On 2 November 2015 at 23:51, Richard Hipp  wrote:
> On 11/2/15, Warren Young  wrote:
>> On Oct 30, 2015, at 11:27 PM, Michal Suchanek  wrote:
>>>
>>> Unless you delete .git your checkout is always in well defined state.
>>
>> Three words: Detached Head State.
>>
>
> Forgot about that one.
>
> I amend my earlier disparaging remarks about Git to include now a
> second reason why Git is not better for developers:
>
> (1) Requires too much mental load
> (2) Detached head state
>
> Note that detached head state is impossible in Fossil and in most
> other VCSs.  (Unsure about Hg.)

Detached head state is the state which you enter when you check out
some random commit id. That is you are not on a tip of any branch. Any
VCS can do that. What git does that other VCS do not is it allows you
to work as normal adding commits on top of the detached head. Unless
you create another branch which serves as as bookmark or pointer to
this head you may have hard time finding it again and it may go away
due to garbage collection on the repo.

This is the result of using the debug interface for everyday tasks.
It's completely fine to allow detached head state but it's not
something the users should see. As in the 'porcelain' commands should
prevent you from using the detached head for anythign but checkout and
bug you to create a branch if you want to commit or automagically
create one.

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] xkcd on git

[Michal Suchanek]

On 2 November 2015 at 20:20, Richard Hipp  wrote:
> On 11/2/15, Michal Suchanek  wrote:
>> In fossil you can have multiple checkouts but there is afaik no
>> in-fossil tool to jump between them
>
> The "cd" command (not even a part of fossil) exists in both unix and
> windows shells and is sufficient to carry you from one check-out to
> another.  Why do you need a "in-fossil tool" to do that?  But perhaps
> I do not understand what you are saying
>
>> and using an external diff tool
>> does not honor repo settings like excludes.
>
> I don't think I understand this statement either.

In git staging area is conceptually a step between working directory
and tip of current branch.

You can easily see the diff (as seen by git with excludes, etc)
between any two of the three.

That's not particularly useful when doing 1 line changes but when you
want to separate the changes you want to commit and changes you want
to stash or keep uncommitted to do more work on them this is quite
useful. And don't tell me nobody ever mixes unrelated and possibly
conflicting changes in the same working directory.

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] xkcd on git

[Michal Suchanek]

On 2 November 2015 at 18:20, Scott Robison  wrote:
> On Mon, Nov 2, 2015 at 4:25 AM, Michal Suchanek  wrote:
>>
>> On 31 October 2015 at 23:33, Richard Hipp  wrote:
>> >
>> > I'll argue that Git is not beneficial even to people who have mastered
>> > its arcane syntax.  Here's why:
>> >
>> > In common usage, Git requires the user to remember the following states:
>> >
>> >(1) The files being editing in the working directory
>> >(2) The files in the staging area
>> >(3) The files local repository head
>> >(4) The files local copy of the remote repository head
>> >(5) The files in the remote repository head
>> >
>> > Git contains commands for comparing and moving content between all of
>> > these different places.  That's a lot to keep in mind.  Everybody has
>> > finite brain capacity.  (Some people have more brain capacity than
>> > others, but it is still always finite.)  The more brain power a
>> > developer devotes to keeping track of the VCS, the less is available
>> > for working on the application or for solve real problems.  To this
>> > end, a VCS ought to minimize the amount of state that the developer
>> > must remember.
>>
>> I don't see how you can eliminate anything except (2). You can
>> directly commit to repo without any intemediate step but having the
>> intermediate step to review your commit before it is set in stone
>> would be especially useful for fossil where you do not want to change
>> the commit, ever.
>>
>> Fossil strives to make (3) (4) and (5) the same with autosync but (3)
>> will diverge from (5) in absence of commit access and when you are
>> offline or commit at the same sync interval somebody advances the
>> remote head. You can also avoid having (4) altogether and just report
>> error when user tries to advance (3) and it is found that it diverged
>> from (5). Resolving or even detecting the conflict without having (4)
>> in some form will be challenging, though.
>
>
> As far as there being a staging area, Fossil does have it and it is called
> the working directory. Tools like stash and revert (in addition to the
> operating system itself) exist to help one manage it. The idea that git's
> implementation of a staging area is superior to fossil's working directory
> is at least arguable (and I find it laughable), but certainly by any other
> name they are conceptually the same thing.

It's different. In git there is Repo - Staging - Workdir and git has
tools for adding changes from workdir to staging and then changing
current staginig area into new commit.

In fossil you can have multiple checkouts but there is afaik no
in-fossil tool to jump between them and using an external diff tool
does not honor repo settings like excludes.

>
> Git is built around this idea that history is mutable. Therefore, keeping
> track of the local repo head, the local copy of the remote repo head, and
> the actual remote repo head imposes a larger cognitive burden than the
> fossil model. Ignoring shunning and deliberate manual changes to a
> repository, fossil is a system that only grows with time. With git, any of
> the three can be modified in ways that make them incompatible with each
> other. With fossil, one only needs to worry about "what has been added that
> might make a merge difficult". With git, one has to worry about what has
> been added, what has been removed, what has been rewritten. The latter two
> can make a merge "impossible".

Rewriting history in git is your choice. You can use git without
rewriting. And really, a merge becoming "impossible" does not really
depend on rewriting. If you have conflicting changes you just have
conflicting changes.

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] xkcd on git

[Michal Suchanek]

On 31 October 2015 at 23:33, Richard Hipp  wrote:
> On 10/31/15, Matt Welland  wrote:
>>
>> Regarding git, other than it's arcane interface (i) the you are paying in
>> learning curve for the additional power that comes from the extra degrees
>> of freedom it provides. A developer willing to invest the time to deeply
>> understand git will likely garner some benefits from that additional power.
>
> I'll argue that Git is not beneficial even to people who have mastered
> its arcane syntax.  Here's why:
>
> In common usage, Git requires the user to remember the following states:
>
>(1) The files being editing in the working directory
>(2) The files in the staging area
>(3) The files local repository head
>(4) The files local copy of the remote repository head
>(5) The files in the remote repository head
>
> Git contains commands for comparing and moving content between all of
> these different places.  That's a lot to keep in mind.  Everybody has
> finite brain capacity.  (Some people have more brain capacity than
> others, but it is still always finite.)  The more brain power a
> developer devotes to keeping track of the VCS, the less is available
> for working on the application or for solve real problems.  To this
> end, a VCS ought to minimize the amount of state that the developer
> must remember.

I don't see how you can eliminate anything except (2). You can
directly commit to repo without any intemediate step but having the
intermediate step to review your commit before it is set in stone
would be especially useful for fossil where you do not want to change
the commit, ever.

Fossil strives to make (3) (4) and (5) the same with autosync but (3)
will diverge from (5) in absence of commit access and when you are
offline or commit at the same sync interval somebody advances the
remote head. You can also avoid having (4) altogether and just report
error when user tries to advance (3) and it is found that it diverged
from (5). Resolving or even detecting the conflict without having (4)
in some form will be challenging, though.

So really fossil is not that much simpler than git. It might try to
hide some of the complexity and it may succedd at some times and not
quite at other times and that's it.

It's true that when you are the sole developer (or the sole developer
with commit access) you can keep (3) (4) (5) the same easily but you
still have to be aware of their existence and avoid actions that would
make them diverge.

>
> Git does a perfectly awful job of minimizing the amount of state that
> the developer must remember.  With the possible exception of

The idea of the git cli interface design is that you build tools on
top of that interface that may try to hide some of the complexity.
Some GUI tools using git for backend exist but it has not happened for
cli. I guess it comes down to the fact that when there is debug
interface and it's not too different from the user interface in terms
of complexity and you have to learn it at some point anyway you just
keep using the debug interface most of the time. Since there is not
much complexity you can remove and keep the system working in common
everyday situations I guess any attempt at making a simplified
interface proves futile.

That said, if the git cli interface was meant for humans from  the
start it could be probably made more humane in some ways.

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] xkcd on git

[Michal Suchanek]

On 30 October 2015 at 23:19, Warren Young  wrote:
> On Oct 30, 2015, at 2:37 PM, Scott Doctor  wrote:
>>
>> Embarcadero RAD Studio incorporates Git, Mercurial, and Subversion into the 
>> IDE.
>
> Yes, it would be nicer if more IDEs had Fossil plugins.
>
> That said, I always have a terminal window up, cd’d into the project, so even 
> when using something like Visual Studio, a quick Alt-Tab and “f ci” is no 
> trouble.
>
>> What I meant was I end up spending much time trying to get the tools to do 
>> what I want it to do versus how it wants to do it.
>
> Examples, please.
>
>> I fully see the utility of a VCS on collaborative projects. My project is 
>> for my own research work and is not used by any clients. I am also the only 
>> one who plays with my code. So some of the utility needed for collaborative 
>> efforts becomes cumbersome for a solo project.
>
> I’ve used Fossil for solo work, and it’s still greatly preferable to the 
> alternatives.  In addition to drh’s points:
>
> 1. Multi-machine sync.  I view laptop computers as a compromise, something to 
> use when you can’t use a desktop computer.  Since I can’t always restrict my 
> coding activities to a single location, that means I occasionally have to 
> sync my work to a laptop, or between two different desktops.  Fossil does 
> that, and does so in a much easier fashion than other DVCSes.  (f all sync!)
>
> Dropbox and such are poor alternatives, since I don’t want my object files 
> and executables sync’d to the cloud, and I don’t want to see a throbby little 
> icon in the corner of my vision every time I save a file.  I want to batch my 
> syncs up, do them on my schedule, and send only source files, no object files.

rsync ..
>
> 2. Deduplication.  Your versioning scheme requires needless copies of 
> unchanged files.  Fossil only stores what is needful, which means I can 
> download the entire history of a project without even thinking about it.
>
> I suspect if you checked all the past versions of your system into a single 
> Fossil repo, it would be about the size of 3 or 4 of your existing “whole 
> project” archives.  So, you’ve got a choice: in the same bandwidth/disk space 
> as a handful of archives, you can have all the history, or just the most 
> recent history.
>
> 3. Comments.  I used to keep a paper log book of the things I was working on, 
> so I could go back later and figure out what I did and why.  Searching the 
> comment stream of a Fossil timeline is far better.
>
> 4. Wiki and technotes.  When I have too much to say to fit into a comment 
> box, I can write an article about it, which gets sync’d to my various 
> development machines.
>
> 5. Tickets.  I used to keep a Wishlist or TODO file in each project, 
> containing the things I wanted to do next.  Tickets do that better, since you 
> can prioritize them, search them, reference them from checkin comments and 
> wiki articles, etc.
>
> You can have my Fossil after I *become* a fossil. :)
>
>> Before I start writing a new function, process, or other modification, I 
>> create a sub-folder of my backup folder which are numbered in sequence. The 
>> file system applies a date to the creation time of the folder which 
>> identifies when the backup was made. I then simply copy my entire project 
>> folder into the backup folder.
>
> This is easier than “fossil ci --tag v1.2.3” or “fossil ci --branch 
> expermental-feature”?
>
> For solo projects, branch merging is nearly trivial, since the chances of 
> colliding changes is near-zero.
>
> And if you do find yourself changing the same area of code on two different 
> branches, it’s easy to say something like “f merge trunk” from the branch to 
> sync changes made in the trunk into the experimental branch, so you can 
> overwrite some of the recent trunk changes without confusing Fossil.
>
>> If I break the code, or decide to revert the changes, I restore the project 
>> from the desired backup folder.
>
> That’s easier than “f up trunk” to toss a bad branch, or “f revert” to toss 
> uncommitted changes, or “f up v1.2.3” to roll back to a prior stable version?
>
>> I am finding them just as cumbersome of a process with an added layer of 
>> things to go wrong.
>
> I rarely find Fossil failing in ways I can’t understand.  And every time it 
> has happened, someone on the list has explained it.

But to understand how it failed you have to be familiar with the
concepts of VCS in general and fossil in particular.

Sure VCS commands are no more difficult than filesystem manipulation
commands. The thing is that your project is already in files so you
have to understand the filesystem concept and its manipulation anyway
whereas with a VCS you have to understand new set of concepts,
features, limitations, and commands that give you access to those.
Subtly different for each VCS, no less.

>
> (For instance, my recent thread about how to clip off a a branch via the 
> command line when the UI can’t do it because it was created em

Re: [fossil-users] SHA1 and security

[Michal Suchanek]

On 30 October 2015 at 00:32, Eduard  wrote:
> Hi Warren,
>
> On 10/29/2015 06:50 PM, Warren Young wrote:
>> On Oct 29, 2015, at 3:40 PM, Eduard  wrote:
>>> On 10/29/2015 02:46 PM, Warren Young wrote:
 (...)
>>> I had read 2/3 of them, yes. Thanks for the third one!
...
>>> I might know (through some other source, e.g.
>>> PGP-signed email) that artifact "abcdef" is genuine, and it shouldn't
>>> matter where I download it from.
>>
>> How many people will be doing such cross-checking?
>>
>> Again I bring up the XcodeGhost example.  People do foolish things in the 
>> name of expediency.
>
> Well, I know I will be doing such cross-checking. Hopefully I'm not the
> only one. Right? ...right?

Seriously, large part of the software out there is not signed in any way at all.

For codebase of non-trivial size (more than 2-3 small files) there is
no way to review the code.

It does not suffice to sign the security software. Since we have the
poor security design dating back to the original Unix implementation
all application are allowed to do anything. There are optional
security extension like selinux that technically do allow sandboxing
applications by now but most applications would fail if running
sandboxed because these are optional non-standard extensions. Who
would bother to cater to people who use those to be able to run their
system securely, right?

So you have to trust every single line of code and makefile you run.
Not just the system tools. *everything* you ever download and execute
on your computer. Even proprietary applications and libraries (how
many vendors do sign these?).

So basically any 'security' on a workstation where you actually do
anything useful is just fake.

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] Why Hash

[Michal Suchanek]

On 16 September 2015 at 05:16, Scott Robison  wrote:
> On Tue, Sep 15, 2015 at 7:46 PM, Warren Young  wrote:
>>
>> On Sep 15, 2015, at 7:01 PM, Scott Robison 
>> wrote:
>> >
>> > I think calling it a non sequitur is not completely fair
>>
>> Stephan stated that Fossil isn’t doing cryptography, therefore SHA-1
>> doesn’t have to be replaced.  Cryptography and message authentication are
>> not the same thing.
>>
>> It’s like pointing out that the bald tires on the car do not need to be
>> replaced because we don’t require that the car be able to climb trees.
>>
>> > It wasn't intended to provide cryptographic security
>>
>> I’m probably just being pedantic, but now you’re doing it, too.
>>
>> “Cryptographic security” implies encryption, which is not being done here.
>>
>> The proper phrasing is “cyptographically-strong message digest algorithm.”
>> The reference to cryptography is only an indicator that the use of a given
>> MD algorithm can be used with some given cryptosystem without compromising
>> its integrity.
>
>
> As I understand "cryptography" to be defined it means "the practice and
> study of techniques for secure communication in the presence of third
> parties". If that is correct, message authentication is most assuredly a use
> of "cryptography to securely identify authenticity". If I'm using a term
> incorrectly, my apologies.
>
>>
>> > It is more likely to detect accidental corruption than deliberate
>> > corruption.
>>
>> I thought that’s what the MD5 bits were for.
>>
>> My sense from reading the file format wiki page is that the SHA-1 bits
>> ensure that blob B, which is intended to appear in the timeline between
>> blobs A and C, was almost certainly inserted into the database at time T_b,
>> where T_a <= T_b <= T_c.  That is, it is primarily a guarantor of checkin
>> ordering.
>>
>> That’s why I’ve been framing the risk as one of potential insertion of a
>> timeline item way in the past.
>>
>> That may be a bogus risk for other reasons, though, since you’d also have
>> to work out how to change all the deltas.
>
>
> The SHA-1 bits ensure (virtually guarantee) that blob B has a unique
> identity so that two contributors don't allocate ID 42 at the same time
> creating a collision in commit IDs. Artifacts are unordered and can
> originally come into a repository from any source in any order. It is
> primarily a guarantor of checkin identity, and the individual cards in the
> manifest control timeline order, date, time, author, etc.
>
>>
>> It’s also occurred to me since my previous post that all the work needed
>> to generate a bogus SHA-1 hash for an HTTPS cert only has to be done once,
>> at which point you now have a reusable cert good for months or years.  The
>> work needed to attack a single timeline entry in Fossil is a one-shot deal:
>> to attack two different nodes in the timeline, you need to do 2x the work.
>
>
> Given that the commit ID is a hash of the manifest, and most of the cards in
> the manifest are F cards, in theory all you have to do is find a useful
> collision with the SHA-1 hash of any file artifact. If you could modify one
> file without changing its SHA-1 hash, everything else in the database would
> still match its hash. Of course, if it is too far back in the history
> (probably even a single merge behind tip) it may never be noticed because
> the project has moved on. And the difficulty still exists of getting it into
> the master repository.
>
>>
>> > simply gaining commit access to the master repository as mentioned the
>> > other day would not be adequate; the maliciously modified artifact would be
>> > rejected by fossil
>>
>> I’m no expert in Fossil’s inner workings, and I have no interest in trying
>> to attack it.
>>
>> I’m just aware that Bruce Schneier and Google’s crypto geeks know things I
>> do not, and I use that awareness to guide my own design decisions.  The last
>> hash-based system I designed used SHA-256. :)
>
>
> I have a lot of respect for Schneier. I would not consider using SHA-1 in a
> security sensitive environment today. This use is less about security and
> more about non-cryptographic hashing, where an (at one time) cryptographic
> strength hash happened to be satisfactory for the needs at hand.
>
>>
>> > I find it far more likely that someone would fork the repo and
>> > contaminate it that way, rebuilding it from scratch, and finding ways to
>> > induce parties to use *that* version of the library instead of the blessed
>> > repo.
>>
>> Clearly so.
>>
>> Always attack the weakest link first, if possible.
>>
>> > * ethernet uses a 32 bit CRC; how much internet traffic goes through
>> > ethernet? Can't really change that because of backward compatibility.
>> > * rsync uses MD5 & a 32 bit rolling checksum / CRC (Adler-32 if I
>> > remember correctly). Can't really change that because of backward
>> > compatibility.
>>
>> That’s why TLS exists.
>>
>> TLS doesn’t solve any weaknesses with Fossil’s use of SHA-1, though.  It
>> just pre

Re: [fossil-users] Why Hash

[Michal Suchanek]

On 11 September 2015 at 17:13, Noam Postavsky
 wrote:
> On Fri, Sep 11, 2015 at 3:57 AM, Michal Suchanek  wrote:
>> On 10 September 2015 at 19:23, Noam Postavsky
>>  wrote:
>>> For example see figure 3 of
>>> http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki
>>>
>>> Both check-ins 3 and 4 are equidistant from the root.
>>
>> And each is on a differnt branch.
>
> This is a fork, not an intentional branch, so both sides are on the
> same branch. Figure 4 shows intentional branching.

That does not really matter. Intentional or not it is a branch and has
to be merged before both commits appear on the same branch. Then they
both get unique number, too.

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] Why Hash

[Michal Suchanek]

On 10 September 2015 at 19:23, Noam Postavsky
 wrote:
> On Thu, Sep 10, 2015 at 9:29 AM, Michal Suchanek  wrote:
>> Given that fossil does not support history rewriting by design the
>> commit number on a particular branch counting from root is unique and
>> stable per branch across all repos.
>>
>> If you release from a single master branch you have a monotonous
>> snapshot number.
>>
>> When you use multiple branches you need to add branch name to have
>> stable unique identifier.
>>
>> This is not viable eg. for git with rebasing.
>
> I think (accidental) forks in fossil would also break the uniqueness
> of the numbering scheme.
>
> For example see figure 3 of
> http://fossil-scm.org/xfer/doc/trunk/www/branching.wiki
>
> Both check-ins 3 and 4 are equidistant from the root.

And each is on a differnt branch.

When you create the merge checkin 5 you create it on a particular
branch and it gets incremental number along the branch even if it
merges multiple checkins from other branch.

>  More complicated
> cases with differing numbers of check-ins on each side of the fork are
> possible.

And in each case the per-branch numbering is exactly defined. And when
you have some master branch on a master repo from which you cut
snapshot releases you get monotonous numbering.

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] Why Hash

[Michal Suchanek]

On 10 September 2015 at 16:54, Martin Gagnon  wrote:
> On Thu, Sep 10, 2015 at 03:29:24PM +0200, Michal Suchanek wrote:
>> On 10 September 2015 at 15:17, j. van den hoff
>>  wrote:
>> > On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
>> > wrote:
>> >
>> >> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
>> >> wrote:
>> >>
>> >>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>> >>> veedeeh...@googlemail.com> wrote:
>> >>>
>> >>>> in a breach of promise to myself to never again argue in favour of this
>> >>>> functionality on the fossil mailing list (it came up a few times over
>> >>>> the
>> >>>> last years):
>> >>>
>> >>>
>> >>> If I understand correctly, the way fossil is designed could cause the
>> >>> numbers to change *even locally* upon a rebuild, or even just a sync.
>> >>> This
>> >>> would probably get confusing.
>> >>>
>> >>
>> >> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> >> option then the order could get even weirder.
>> >
>> >
>> > well, I'm only talking about the ordinal numbers chronologically 
>> > enumerating
>> > the timeline checkin(!) entries. this enumeration will not change as a
>> > consequence of rebuild, right? it might change after a sync against some
>> > remote repo if there are incoming checkins chronologically interleaved with
>> > my own, sure, but so what? the relative numbers would be just a (somewhat
>> > "volatile") convenience measure _locally_. and I agree with another recent
>> > post that this would primarily concern the CLI. what I mean: go ask some hg
>> > users when they last did use sha1 hashes for specifying checkins in their
>> > interaction with hg (which supports both the ordinals as well as the hashes
>> > for doing so) and how often the presence of those numbers confused
>> > communication with other developers in their project. I'm quite sure they
>> > _never_ specify sha1 hashes to denote checkins in any small to medium-sized
>> > project  below 10^4 checkins (currently
>> > this still includes fossil itself). not so sure about the "communication"
>> > issue if users forget the potentially 'volatile' nature of the relative
>> > enumeration, but this just can't possibly be a big issue ...
>> >
>> > I therefore just maintain it would be "nice to have". it sure ain't a 
>> > killer
>> > feature, I admit ...
>> >
>>
>> Given that fossil does not support history rewriting by design the
>> commit number on a particular branch counting from root is unique and
>> stable per branch across all repos.
>>
>> If you release from a single master branch you have a monotonous
>> snapshot number.
>>
>> When you use multiple branches you need to add branch name to have
>> stable unique identifier.
>>
>> This is not viable eg. for git with rebasing.
>
> Even in fossil it could be a problem, it cannot re-write history but a
> branch is just a tag that can change. The identifier will change
> after moving checkins on a branch.
>

If you can remove the tag that denotes the branch name from a branch
and put it on another branch then the repo-unique identifiers will
change since the branch name part will change, of course. The
branch-unique identifier is stable, however. It can for example denote
commits on currently checked out branch fine.

And even with the ability to rename branches the branch name+commit
number identifier is unique at any given time. Just not stable wrt
branch rename which is understandable.

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] Why Hash

[Michal Suchanek]

On 10 September 2015 at 15:17, j. van den hoff
 wrote:
> On Thu, 10 Sep 2015 08:05:09 +0200, Stephan Beal 
> wrote:
>
>> On Wed, Sep 9, 2015 at 10:43 PM, Baruch Burstein 
>> wrote:
>>
>>> On Wed, Sep 9, 2015 at 10:12 PM, j. van den hoff <
>>> veedeeh...@googlemail.com> wrote:
>>>
 in a breach of promise to myself to never again argue in favour of this
 functionality on the fossil mailing list (it came up a few times over
 the
 last years):
>>>
>>>
>>> If I understand correctly, the way fossil is designed could cause the
>>> numbers to change *even locally* upon a rebuild, or even just a sync.
>>> This
>>> would probably get confusing.
>>>
>>
>> Correct. And if i'm not mistaken, if you rebuild with the --randomize
>> option then the order could get even weirder.
>
>
> well, I'm only talking about the ordinal numbers chronologically enumerating
> the timeline checkin(!) entries. this enumeration will not change as a
> consequence of rebuild, right? it might change after a sync against some
> remote repo if there are incoming checkins chronologically interleaved with
> my own, sure, but so what? the relative numbers would be just a (somewhat
> "volatile") convenience measure _locally_. and I agree with another recent
> post that this would primarily concern the CLI. what I mean: go ask some hg
> users when they last did use sha1 hashes for specifying checkins in their
> interaction with hg (which supports both the ordinals as well as the hashes
> for doing so) and how often the presence of those numbers confused
> communication with other developers in their project. I'm quite sure they
> _never_ specify sha1 hashes to denote checkins in any small to medium-sized
> project  below 10^4 checkins (currently
> this still includes fossil itself). not so sure about the "communication"
> issue if users forget the potentially 'volatile' nature of the relative
> enumeration, but this just can't possibly be a big issue ...
>
> I therefore just maintain it would be "nice to have". it sure ain't a killer
> feature, I admit ...
>

Given that fossil does not support history rewriting by design the
commit number on a particular branch counting from root is unique and
stable per branch across all repos.

If you release from a single master branch you have a monotonous
snapshot number.

When you use multiple branches you need to add branch name to have
stable unique identifier.

This is not viable eg. for git with rebasing.

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] please compile official fossil builds with https support

[Michal Suchanek]

Hello,

On 10 June 2015 at 21:37, Eric Rubin-Smith  wrote:
>
>
> On Wed, Jun 10, 2015 at 3:30 PM, Richard Hipp  wrote:
>>
>> On 6/10/15, Eric Rubin-Smith  wrote:
>> >
>> > If you are worried that some people don't want the bloat of openssl in
>> > their base fossil, perhaps provide both options on the site?
>> >
>>
>> It's not a question of bloat, its a question of whether or not we
>> require the user to have previously done "apt-get install openssl
>> libssl" (or whatever other magic incantation is required to get the
>> right shared libraries running).
>
>
> I guess I had assumed you could bake it in statically.  Is that a non-option
> for yall?
>

There is certainly one issue to be aware of.

When you link dynamically with libssl then your distribution is
responsible for updating libssl in response to libssl vulnerabilities.

When you link statically with libssl you are responsible yourself for
producing an updated build every time a security fix is applied to
libssl regardless of any (lack of) changes in the fossil code.

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] GitHub question. Was: Git-v-Fossil.

[Michal Suchanek]

On 16 March 2015 at 23:08, Joerg Sonnenberger  wrote:
> On Mon, Mar 16, 2015 at 11:01:21PM +0100, mario wrote:
>> "Social network" is a nice metaphor.  But it's also just a side-effect
>> of having a data silo.
>
> Actually, I think that's the far bigger item. GitHub has managed
> something which SourceForge never had -- a stable service.
>
>> Most developer interactions center around the issue tracker.  Which is
>> pretty.  And often just used as discussion board with ticket numbers.
>
> That's not my experience with GitHub. Until recently, the issue tracker
> was a bad joke. The central communication medium on GitHub was always
> the pull queue...
>

Either way, github has managed these things:

1) it's a general purpose place to publish any code (with relatively
reliable service)
2) it's a place to get feedback for your code (in whatever form) that is usable

SF fails in 2) due to their bug tracker being a bad joke to this date
and lack of any pull request tracker. LP fails in 1) due to their
focus on Ubuntu.

Also it seems that focus on pull requests rather than traditional bug
reports was a good move on part of github. It was a void they have
filled with their service.

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] New skin: Blitz

[Michal Suchanek]

On 16 March 2015 at 15:13, James Moger  wrote:
> I sent DRH a new bundle with some tweaks.
>
> - set padding on  instead of  in .mainmenu
> - adjust font-sizes on diff panels to 1rem, Blitz is 1rem=10px.  0.85rem is
> too small.
> - set the timeline checkin-id to lowercase rather than uppercase
>
> As for the content-width... the reason to set a max width is to avoid
> distortion of content.  It's a common practice in webapps.  This is often
> coupled with responsive design where components are shown/hidden based on
> CSS media queries.  This allows a UI to scale gracefully from handhelds to
> desktops.  Most current CSS toolkits feature responsive layout classes, but
> adoption of one would require changes to the Fossil-generated HTML, not just
> wrapping a header and a footer around the current generated content.

Maybe I am stating the obvious but it does not make sense to scale the
main content area to arbitrarily wide screens. At some point the lines
get so long they are pain to read. Of course, this length is
individual to some extent and it would be nice tunable parameter but
there certainly should be a limit. When you have headers and footers
that you can reflow beside the main content and a toolkit that has the
ability it's fine but that still does not extend to arbitrarily wide
screen.

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] GitHub question. Was: Git-v-Fossil.

[Michal Suchanek]

On 14 March 2015 at 18:48, Andy Bradford  wrote:
> Thus said Richard Hipp on Sat, 14 Mar 2015 00:05:07 -0400:
>
>> Am I  wrong to think  that clicking through  the changes in  a project
>> (not  necessarily  from the  beginning,  but  from some  signification
>> event,  say  the  most  recent  release)  in  chronological  order  is
>> something that people might commonly want to do?
>
> It's certainly something  I commonly want to do, and  sorely miss when I
> have to use github. I use gitk to fill the voi d, but it too is lacking.
> I prefer that the tools I use  help me reason effectively about the data
> I'm looking at  and something like clicking through changes  helps me do
> this for a series of checkins.
>
> But I'm just  expressing my bias---I don't know what  other people might
> commonly want to do. :-)
>

Yes, it's useful.

And time and time again I find the web tools lacking so I just clone
the repository locally and use fully functional local tools.

I always view the web interfaces as a sort of preview of the VCS
content which you can use to determine if the patch you are looking
for was pushed or to determine if the project code looks interesting
(as opposed to the name and short description).

The time when web interfaces are fully functional looks far far away.
They are one of the available tools and they complement the tool set
but are not replacement for the others.

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] Fossil vs. Git/Mercurial/etc.?

[Michal Suchanek]

On 31 December 2012 04:41, Mike Meyer  wrote:
>
>
> Nico Williams  wrote:
>>Go back through those 30 posts you mentioned.  Go back to the very
>>first one from me.  I tried to be concise and wrote just three
>>paragraphs that, IMO, captured what was needed.  I certainly did not
>>say "I want git rebase in fossil" and then watched the fireworks --
>>no, I explained *concisely* (or at least that was my aim).
>
> No, you said "I want something slightly different than git rebase in fossil." 
> Concise? Yes. Precise? No. Well-defined? No. Useful? No.
>
>>If I had written a ten-page post explaining in excruciating detail
>>what rebase is, why it matters, and how to adapt it to the Fossil
>>philosophy, who -but who!- would have read that first post?  I was
>>being (I thought!) considerate.  And judging by last night's 30 posts,
>>would it have made any difference to post a thesis-length argument for
>>rebase?  And if so, how was I to know that?  Or should I have given up
>>at the very first sign of trouble?
>
> That depends on the goal. If you want to troll the list, then arguing for 
> rebase is a good choice. If you want fossil to incorporate a solution for 
> your problem, you should provide the information people are asking for. Given 
> how poorly your attempt to work with the comunity has gone, giving up now 
> isn't an unreasonable option. On the other hand, if you want to be able to 
> use fossil, and are willing to work with us to solve your problem instead of 
> arguing about what "rebase" does, you can start by answering our questions.
>
> For instance, you haven't answered any of my questions. You've explained in 
> detail what rebase does, but that's irrelevant, because rebase is only an 
> approximation to what you want, and you haven't explained how what you want 
> is different in sufficient detail for us to figure out what that is. You 
> haven't shown us why the existing solutions are "to much work". You haven't 
> said what kind of interface you want (otherr than "interactive rebase", and 
> you haven't said what that interface looks like!). You  may think you have, 
> but your opinion here doesn't matter: if we don't have a clear understanding 
> of what you want, we don't have it, and the onus is on you to provide it. The 
> best way to do that is by answering our questions.

Rebase is a mass cherry-pick script, basically.

You have an upstream trunk U and you branch B and in the simplest form
rebase cherry-picks every single commint in B from the branching point
to the tip one by one on top of U and marks the result as B. As has
been pointed out this marking the result as B is the only destructive
part which loses the original B and is unnecessary.

Now the more involved version allows you to control how commits are
picked. rebase presents you with a rebase recipe which shows the list
of commits in B and all are marked with the default 'pick' which
results with the above basic behaviour. You can edit the recipe to
drop some commits, change the order in which they are picked, mark
some for editing so rebase stops on them, mark some for squashing so
rebase folds them into the previous commit. You can even select if the
commit message of the squashed commit is appended or dropped but to
edit the resulting message you have to run rebase again and mark for
edit.

Git add comes with a tool which allows you to pick only some files or
some hunks from the checkout when creating a commit. It just shows the
changed files and the hunks in the picked files one by one and asks
you which to add. Sadly this tool is quite poorly integrated in git.
When cherry-picking this cannot be used. To actually split a commit
during rebase you have to mark the commit for editing, undo it, and
then add parts of that commit as multiple commits possibly using the
interactive add tool. When the commit adds files this is very
error-prone.

You can see that these tools are not available in fossil and with its
web interface they could be presented in more friendly way than what
the git commandline tools present. You can also see that while git has
them they are not quite stellar.

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] Is there a setting to make fossil handle UTF-8 correctly in file names and folder names?

[Michal Suchanek]

On 28 November 2012 20:56, Richard Hipp  wrote:
>
>
> On Wed, Nov 28, 2012 at 2:50 PM, Frans van Dunné 
> wrote:
>>
>>
>> Is this a configuration issue? Or can fossil not handle special
>> characters in file and folder names?
>
>
> Fossil is suppose to handle non-ASCII characters in filenames correctly.  If
> it does not, that is a bug.  What version of Fossil are you running?  Can
> you send in a detailed bug report with steps to reproduce the issue?

I guess this issue stems from different Unicode handling on the OS
level. While Ubuntu stores whatever you write OS X normalizes
(decomposes?) Unicode on HFS. Then what you write as file name on
Ubuntu will be transferred to the Mac, there normalized by the OS to a
(possibly) different string that looks the same and on subsequent
transfer to Ubuntu a new file or directory with seemingly same name
may be created.

Since OS X also conflates case by default you can model this somewhat
more visibly by transferring a file to OS X and there changing the
case of the file name. You will have to actually move the file twice
because just changing the case fails as any move to itself does.

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] Fossil design error and possible ways to fix it

[Michal Suchanek]

On 22 November 2012 14:35, Jan Nijtmans  wrote:
> 2012/11/22 Richard Hipp :
>> Fossil understands check-in comments and ticket text to be Wiki/HTML.  Let's
>> say that the mimetype is "text/x-fossil-wiki".  This approach worked well
>> for us on CVSTrac (which was where many of the ideas in Fossil originated)
>> because it allowed hyperlinks to other check-ins, tickets, wiki, etc to be
>> embedded in the check-in comment text.
>
>
> I think I would fix that in the comment preprocessor. Before being
> committed, comments already have the pre-processing step that
> lines starting with '#' are eliminated. So, what of the following
> processing would be done in addition:
> - All '<', '>', '&', single and double-quotes are translated to their html
>   equivalent. < > & ' "
> - All newlines are translated to '\n' (newline followed by ''),
>   except for the last newline in the comment.
> - Maybe even all spaces translated to   and all tabs with
>   multiple  'es. (I don't really think this is necessary)
>
> Then the comment text is valid html, but will look like plain-text
> when viewed, nothing else needs to be changed.
> And a configuration option can be introduced whether those two additional
> proprocessor steps are wanted for the fossil client or not. No changes at
> all to the fossil server.
>
> Advantage:
> - Fully upwards/downwards compatible.
> - The main problem of having to html-escape the characters manually
>   is solved: the commit-message preprocessor does it for you.
> - no new mime-type has to be used.
> - Older commit-messages are displayed unchanged.
> - If more elaborate wiki markup is needed, it can always be
>   edited later in the UI.

The major disadvantage is, of course, that this ugly mess will be
likely visible in the command line view of the commits and that it
does not allow changing the commit message format. And this whole
thing is probably about allowing multiple commit formats to exist
cleanly in one repo.

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] Fossil design error and possible ways to fix it

[Michal Suchanek]

On 22 November 2012 14:05, Richard Hipp  wrote:

> (3) Add a "use text/plain" mark to new check-in comments.  Check-in comments
> (and ticket text) are rendered in text/x-fossil-wiki by default but as
> text/plain if they contain the new mark.  There are a couple of possible
> ways to add the "use text/plain" mark:
>
> (3a) Extend the artifact format by adding optional mimetype fields to the
> end of C and J cards.  (See
> http://www.fossil-scm.org/fossil/doc/trunk/www/fileformat.wiki for
> background information on what C and J cards are.)  This is the cleanest
> approach, but it means that new check-ins could not be understood by older
> versions of Fossil.  It would force people to upgrade.

Another alternative is to treat cards without mimetype as
text/x-fossil-wiki and allow for creating cards without mimetype when
the text/x-fossil-wiki is set as default. You can then pick when
upgrade to new fossil is required to access a particular repository
and have the support for new formats available.

The problem is with syncing commits and/or tickets from other
repositories. Since there are no commit hooks yet it is not possible
to reject artifacts that do not conform to the repository policy.

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] status of TODO list (was Re: comparison with Git)

[Michal Suchanek]

On 13 October 2012 16:45, Richie Adler  wrote:
> Richard Hipp escribió:
>> On Sat, Oct 13, 2012 at 4:06 AM, Gour > > wrote:
>>
>>
>> Now, I'm curious about some of the items from the TODO list
>> (http://www.fossil-scm.org/index.html/wiki?name=To+Do+List)
>> and their status:
>>
>> * Uncommit
>>
>> All what I need is simple mechanism to quickly 'fix' some wrong commits
>> without tinkering deep into the commit history.
>>
>> ...
>>
>>
>>
>> The idea is when one creates short-lived feature branch, experiment
>> with it a bit, and when it's ready simply commits to the 'main' branch
>> not wanting to keep it any longer.
>>
>>
>> Deleting content from a repository is scary.  A bug in the delete logic could
>> easily cause loss of information.
>>
>
> I'm mostly an outsider (and very, very happy user of Fossil in its current
> state), so take my coment with a pinch of salt, but:
>
> Doesn't strike you as odd this sudden influx of requests of "make Fossil more
> like Git!"? It's almost as if disgruntled users of Git want to have a Git-like
> program, even importing their defects (or, let's be generous, "differences in
> design philosophy"), but with a more friendly interface. "No matter if this
> bothers or causes some worry or complication to current Fossil users or even
> to its implementors: we want our Git-lite program so we can have all the
> things we like and not have the Git manual tattooed to our inner eyelids!"
>

No, it's not odd.

Both fossil and git have their strengths and shortcomings. Of course,
some are inherent in the design but others are just lack of a script
to perform a function similar to the function of the other system (eg.
rebase). Some would perhaps require some modification to fossil or
burying fossil in a pile of script wrappers (eg. commit hooks).

While writing that script is obviously possible locally that
functionality stays local and non-portable.

Some feature requests might come from the lack of understanding of
existing features but others are calling for features that are sorely
missing in fossil however you look at it. Of course, you might not
need them for your project (yet) but that does not mean they are
useless.

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

[Michal Suchanek]

On 12 October 2012 00:21, Ron Wilson  wrote:
>
> I would think that rebasing would do the same number of merges, just
> that it automates those merges.
>

Yes, that's what rebasing is.

Also rebasing based development process keeps branches shallow and the
case with commits interleaved wildly does not really happen. Note that
you rebase against upstream that is independent of your branch so the
case when you merge upstream into your private branch does not really
happen. Upstream can at times include some of your commits which are
then eliminated from your branch on rebase because they are already
included in the upstream branch.

The thing what rebase gives you over single merge are readable patches
that are either accepted and included at the tip of upstream or can be
applied on top af a release tarball or can be basis for furthere
development.

With single merge you get a huge merge commit which can be used the
same way except it makes no sense on its own, can't be separated into
incremental changes that make sense, and when you base further
developmnet on top of it (eg. the merge was rejected by upstream) you
get those long branches that plug into ancient project history with
wildly interweaved 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] Fossil enhancement idea. Was: trouble handling text files from SQL Server 2012

[Michal Suchanek]

On 15 September 2012 04:20, 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.
>

This is not such a good idea. Converting well-formed UTF-16 into UTF-8
is lossless and fully reversible so even in the case some random
binary file is mis-detected as UTF-16 text it is not clobbered by the
conversion given well-formedness is a requirement for it to be
detected so. As long as the resulting object is properly marked as
converted or the conversion is only used for generating diffs, not
storing the file this is fine.

SJIS conversion and CR/LF conversion do not behave that way.

CR/LF conversions are very useful for projects spanning multiple
platforms, though.

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

[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

[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

[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

[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

[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

[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] Please make shunning a first class feature.

[Michal Suchanek]

Hello

I did not try this but I think cloning should not copy shunned artifacts.

So you can create a smaller repo by making another clone.

HTH

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] Is there a way to make the web server follow symlinks?

[Michal Suchanek]

On 29 August 2012 13:20, Stephan Beal  wrote:
> On Wed, Aug 29, 2012 at 12:15 PM, Stuart Rackham  wrote:
>>
>> Yes, the "allow-symlinks" setting is on, in this particular repository
>> there are shared resources (CSS files and images) that are common to
>> ...a symlink and load the actual file artifact that it refered to.  This
>>
>> is what you expect when you read a file via a symlink and is how a web
>> server would treat the file if it resided on a file system.
>
>
> That is a reasonable/realistic assumption, but symlinks support was grafted
> on much later and almost certainly has a corner case or three remaining
> (symlinks aren't platform-portable, and were not originally supported at all
> by fossil).

Aside from not being platform-portable following symlinks also
requires checking if they point outside of the checkout tree or not.

The alternative - using proper relative references to the files in
another directory resolves the symlinks in the browser which is
portable and can only work for files that shall be accessible.

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] Fossil version 1.23

[Michal Suchanek]

On 11 August 2012 01:33, Chad Perrin  wrote:
> On Fri, Aug 10, 2012 at 10:13:06PM +0200, li...@martijn.coppoolse.com wrote:
>>
>> ...but of course, that doesn't contain a link to the download(s).
>> OTOH, why do you need to keep a link to this specific version, once
>> it gets older?
>
> Publishing an article about the current release version, for instance,
> would ideally be able to point to something about the specific release
> version, because otherwise in a year's time the article might be called
> something like "Fossil SCM 1.23 Provides New Features" with a link to
> release notes for Fossil SCM 2.1 or something like that.

The page http://www.fossil-scm.org/download.html includes all the versions.

I guess adding anchors so that a link to the part about a particular
release can be crafted would suffice.

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] [OT] Who's interested in project management & collaboration tools? And...

[Michal Suchanek]

On 9 August 2012 16:56, Chad Perrin  wrote:
> On Tue, Aug 07, 2012 at 08:23:04PM +0200, Michal Suchanek wrote:
>> On 7 August 2012 20:10, Miles Fidelman  wrote:
>> >
>> > an email, recipient clicks, opens in browser, icon appears on desktop for
>> > future access).
>>
>> Now the part about icon appearing on desktop is really scary.
>>
>> I am sure that on my system it will not appear ;-)
>
> Icon on desktop?  What is this "icon on desktop" of which you speak?
>
> (Some of us don't use the common WIMP model.)

Well, that's one of the reasons. I don't have icons on the desktop.

Still I do have the Desktop directory which hold what the DE thinks is
on my desktop and clicking a link in a browser is not going to place a
file in there. I will see to that.

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] [OT] Who's interested in project management & collaboration tools? And...

[Michal Suchanek]

On 7 August 2012 20:10, Miles Fidelman  wrote:
> Michal Suchanek wrote:
>>
>> On 6 August 2012 19:21, Miles Fidelman  wrote:
>>
>>
>>>
>>> My personal observation has been that even with a tiny group, an email
>>> containing a list of action items very quickly yields a thread of dozens,
>>> or
>>> hundreds of follow-ups - requests for details, Q&A, status updates,
>>> nagging,
>>> . - and sorting through all that info is a real pain and time sink,
>>> not
>>> to mention confusing.
>>
>> Yes, that's what IRC is good for. You get much of the details, Q&A,
>> and whatnot sorted out in real time before you start writing a
>> document, and only few revisions are needed to finish then. Also for
>> status updates that are not obvious as bugs closed or patches pushed.
>>
>> And if you meant that email is bad for TODO list it definitely is.
>> Sane people use a text file tracked in vcs with project code or a wiki
>> page or an issue tracker. Unlike email all these media tend to persist
>> in the same place and are not pushed away by more recent messages.
>>
>>> Now if that first message was "smarter" - so that responding updated the
>>> original (like editing a wiki page by email) - a lot of the pain and
>>> confusion would go away.
>>
>> I think google tried something like that with Wave ;-)
>
>
> Well, yes and no.  What was really disappointing about Wave was that it was
> closed.  It didn't even send email notifications of an update to a Wave.
>
>
>>>> Note that most wikis are versioned, and some can use a vcs as backend
>>>> directly. So more permanent stuff not part of documentation that is
>>>> not to be fished in irc logs and mail archives typically ends up on a
>>>> wiki or a developer blog.
>>>
>>>
>>> That nicely captures what I'm trying to accomplish.  In a sense,
>>> TiddlyWiki
>>> meets Fossil-SCM built on HTML5 and a P2P protocol is kind of what I'm
>>> trying to achieve.
>>
>> Fossil is almost but not quite such a wiki. It has built in wiki that
>> is not versioned, and versioned documents that are not editable
>> through the fossil web UI. If you modified fossil to make the
>> versioned documents editable you can use the clone and autosync
>> features to propagate changes.
>
>
> That's close to what I have in mind.  I'm hoping to push the code into the
> documents themselves, and store things either in browser storage or local
> file systems - making it all a lot more accessible for folks who don't want
> to install code.
>
> For a software development team, it makes lots of sense for everyone to
> install a copy of Fossil (or whatever).  But for an action item list, it's

You don't need to install a copy of fossil to edit the wiki. It's
accessible through the browser, after all.

But you can install fossil and make a clone of the wiki, and the
autosync ensures that it is updated continuously.

> really a lot easier if everything happens through email and browser (compose

And with a wiki it does happen through browser.

I don't see how email fits in here since you yourself claim how horrible it is.

> an email, recipient clicks, opens in browser, icon appears on desktop for
> future access).

Now the part about icon appearing on desktop is really scary.

I am sure that on my system it will not appear ;-)

Cheers

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] [OT] Who's interested in project management & collaboration tools? And...

[Michal Suchanek]

On 6 August 2012 19:21, Miles Fidelman  wrote:

> Michal Suchanek wrote:

>> >From the startup side - with like 3 people on the project the
>> contribution of some software for project organization is questionable
>> at best. The overall attitude is geared towards doing stuff, not
>> managing stuff.
>>
>> >From the free software side - the number of people on any given
>> project is limited to like 5. Most projects either have no more major
>> contributors or naturally decompose into multiple parts where the
>> number of people involved in any given part is very low. eg. the Linux
>> kernel has subsystems, ...
>> Very few people are major contributors to more than 1-2 projects at a
>> time.
>>
>> To organize an IRC session of 3-6 people is not overly difficult, and
>> given the nature of typical FS schedule model of "done when done"
>> there is no real press. The problem seems to lie more in lack of time
>> and contributors than in organizing contributors.
>
>
> My personal observation has been that even with a tiny group, an email
> containing a list of action items very quickly yields a thread of dozens, or
> hundreds of follow-ups - requests for details, Q&A, status updates, nagging,
> . - and sorting through all that info is a real pain and time sink, not
> to mention confusing.

Yes, that's what IRC is good for. You get much of the details, Q&A,
and whatnot sorted out in real time before you start writing a
document, and only few revisions are needed to finish then. Also for
status updates that are not obvious as bugs closed or patches pushed.

And if you meant that email is bad for TODO list it definitely is.
Sane people use a text file tracked in vcs with project code or a wiki
page or an issue tracker. Unlike email all these media tend to persist
in the same place and are not pushed away by more recent messages.

Another horrible issue tracking tool used by some projects is web
forum software which leads to almost as much confusion as email except
the messages are editable so there is some chance that you can get
current summary at the start of thread.

When some people pick on obviously wrong tool for the job and insist
on using it they are doomed and there is nothing you can do about it.

>
> Now if that first message was "smarter" - so that responding updated the
> original (like editing a wiki page by email) - a lot of the pain and
> confusion would go away.

I think google tried something like that with Wave ;-)

>
>>
>> Note that most wikis are versioned, and some can use a vcs as backend
>> directly. So more permanent stuff not part of documentation that is
>> not to be fished in irc logs and mail archives typically ends up on a
>> wiki or a developer blog.
>
>
> That nicely captures what I'm trying to accomplish.  In a sense, TiddlyWiki
> meets Fossil-SCM built on HTML5 and a P2P protocol is kind of what I'm
> trying to achieve.

Fossil is almost but not quite such a wiki. It has built in wiki that
is not versioned, and versioned documents that are not editable
through the fossil web UI. If you modified fossil to make the
versioned documents editable you can use the clone and autosync
features to propagate changes.

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] Time for a new release?

[Michal Suchanek]

On 6 August 2012 17:00, Stephan Beal  wrote:
> On Mon, Aug 6, 2012 at 2:36 PM, Michal Suchanek  wrote:
>
>>
>> I could easily give you a few things that I still find broken in
>> fossil, and I guess I am not the only person ;-)
>
>
> There will ALWAYS be things to fix/improve. That's the beauty of software.

I beg to differ. There should be some feature set which when
implemented bug-free would make a piece of software finished. Of
course, there tend to be minor issues even in 'finished' software of
any non-trivial complexity but they should be few and far apart.

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] Time for a new release?

[Michal Suchanek]

On 6 August 2012 14:14, Richard Hipp  wrote:
> It has been a long time since we have done an official release of Fossil
> with prebuilt binaries.   We should probably do another soon.  Any
> objections to making the tip of trunk the next official release (version
> 1.23)?

Given that next to nobody who uses fossil uses the release I guess
next release is overdue.

On the other hand, are the patches that people apply really included in tip?

Is there a list of fixes since 1.22?

I could easily give you a few things that I still find broken in
fossil, and I guess I am not the only person ;-)

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] [OT] Who's interested in project management & collaboration tools? And...

[Michal Suchanek]

Hello,

On 5 August 2012 03:28, Miles Fidelman  wrote:
>  where are they and how do I get their attention?
>
> Hi Folks,
>
> Open source software development involves a lot of distributed collaboration
> - and I expect that many folks here, like me, are involved in one or more
> projects, and dealing with all kinds of project management administrivia.
> So.. I wonder if I might solicit opinions

This is somewhat interesting question.

I think that you are targetting way narrower niche than you might expect.

I am not saying that project management cannot be improved.

But you must ask this question: who is the person buried in a pile of
yellow stickies that will use your software?

>From the large corporate side project managers would possibly
appreciate your software but most likely they are bound to use a
solution that is standardized throughout company. The overall attitude
is geared toward using proven and well established things.

>From the startup side - with like 3 people on the project the
contribution of some software for project organization is questionable
at best. The overall attitude is geared towards doing stuff, not
managing stuff.

>From the free software side - the number of people on any given
project is limited to like 5. Most projects either have no more major
contributors or naturally decompose into multiple parts where the
number of people involved in any given part is very low. eg. the Linux
kernel has subsystems, ...
Very few people are major contributors to more than 1-2 projects at a time.

To organize an IRC session of 3-6 people is not overly difficult, and
given the nature of typical FS schedule model of "done when done"
there is no real press. The problem seems to lie more in lack of time
and contributors than in organizing contributors.

The exception to this rule would be projects like system distributions
which both have many contributors and attempt regular release
schedule.

Note that most wikis are versioned, and some can use a vcs as backend
directly. So more permanent stuff not part of documentation that is
not to be fished in irc logs and mail archives typically ends up on a
wiki or a developer blog.

Note that Linux has eg. MAINTAINERS file in vcs directly with code,
many projects also maintain TODO.

What is hard to share with wikis and irc (if needed) is stuff like
diagrams but I don't expect richer media to be easily editable through
the web any time soon due to lack of standards.

I guess you can also expect some interest from established but not
overgrown businesses with like tens of employees.

Google tells me there are ready made commercial solutions so in cases
when enough money is involved solutions already exist. Sure, they are
possibly not on-site or not based on open standards but that tends to
appeal little to managers. They want a solution now so that their
project can be managed immediately.

And I guess you are not reaching people. How would you reach people
through kickstart is a mystery to me, tbh. It's not like people
regularly look there thinking along the lines of "what am I going to
sponsor today?"

All in all if you are project manager you can try to develop a project
management software as a hobby but expecting $65k funding from random
people does not look realistic.

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] templates (WAS: Re: The future of markdown-in-fossil(

[Michal Suchanek]

On 3 August 2012 16:43, Stephan Beal  wrote:
> On Fri, Aug 3, 2012 at 4:30 PM, Michal Suchanek  wrote:
>>
>> I don't think that doing this is desirable. fossil status should be
>> fossil status.
>
>
> And i agree entirely, i just posted the idea as a possible extension of the
> custom commands (since this is an evolutionary process, and custom commands
> will enable new directions for growth).

I guess renaming commands (or replacing or aliasing, ..) could be a
local configuration, similar to user accounts used for the web UI,
CR/LF conversion, commiter email, and whatnot.

Then you can have a  custom command synced from upstream and locally
alias it to replace one of the standard commands - or not.


>>
>> Still if you are editing and
>> testing the pages in the browser it might be good idea to make
>> whatever you save a 'checkout' which is only synced when you 'commit'
>> it. Otherwise you are going to make tons of small meaningless commits
>> as you edit small details of templates and stylesheets.
>
>
> This could be done using something like the wiki's preview feature, where
> the client submits wiki content and the server renders it without saving it.

This is rather difficult currently. You have to use force-refresh for
CSS changes to show in the browser. Could be easily fixed with
referencing style-draft-.css or style-.css rather than
style.css. Or with a proper date and cache control in the header I
guess.

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] templates (WAS: Re: The future of markdown-in-fossil(

[Michal Suchanek]

On 3 August 2012 16:03, Stephan Beal  wrote:
> On Fri, Aug 3, 2012 at 3:49 PM, Michal Suchanek  wrote:
>>
>> And how do you prevent malicious code import through synchronization?
>
>
> The same way Windows does, of course: "This app comes from god-only-knows
> where. Do you want to run it?"
>
> ;)
>
> i have absolutely no idea, to be honest.

Well, you don't because your system has no security.

No system in wide use today has.

>
>>
>> This is the exact same thing. Either you don't import or don't use
>> what you import or you are vulnerable to what you import.
>
>
> The difference with custom commands, compared to what is currently syncable,
> is that they will have a lot more power via access to stuff which was not
> accessible before. e.g. a query API has been added to the scripting language
> (th1). One very interesting (under consideration) feature of custom
> commands/pages is that we could _potentially_ offer an option to direct
> built-in commands to a custom command. If such things are synced, then i
> might get your version of "fossil status" instead of mine, and that would
> upset me. The custom commands API currently offers nothing which will allow
> one to change a repo's state and there are NO plans to add such APIs, for
> repo integrity reasons. Even so, with greater power comes bigger cans of
> worms, so any synchronization must be carefully considered.

I don't think that doing this is desirable. fossil status should be
fossil status.

You might want to write a separate script to replace it. It might be
useful to be able to make fossil mystatus, too.

The web interface is optional and it is fine to be able to change it
with synchronization. Of course, if you run fossil serve and browse to
the web interface which is synchronized from upstream you are open to
browser attacks. But the same applies if you browse HTML documentation
included in the project (or PDF documentation with overly clever PDF
reader), or run projects build or other scripts, or run the binaries.

>
> Initial templates/commands support _might_ live in a new table of its own
> (this is still undecided) which will initially not be syncable but would
> eventually be made so, _probably_ via an extension of the "config" command
> (or something equivalent). They might live in the artifacts table (where
> they could be versioned and synced as normal artifacts), and whether or not
> to version custom pages/commands is a decision which has not yet been made
> (as always: opinions on the matter are welcomed). It might be interesting,
> and wouldn't be much work, to provide several methods for storing custom
> commands: config table, artifacts, and/or local files. e.g. for prototyping
> this support i use local files, and once i'm (eventually) satisfied with the
> overall model i'll figure out (hopefully with the help of the community)
> where best to store such things.

Versioning them is probably a good idea. Still if you are editing and
testing the pages in the browser it might be good idea to make
whatever you save a 'checkout' which is only synced when you 'commit'
it. Otherwise you are going to make tons of small meaningless commits
as you edit small details of templates and stylesheets.

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] MIME types in Fossil's document server

[Michal Suchanek]

On 3 August 2012 15:54, Michael Richter  wrote:
> I'm having a weird problem serving up files in my /doc/tip/*.  Some of the
> files I access through that tree are source files.  If the source files are
> foo.m (Mercury source), fossil serves them up as MIME type text/html and it
> gets displayed nicely in my browser (Firefox 14).  If, however, the source
> files are foo.sno (SNOBOL4 source), fossil serves them up as… well, I'm not
> absolutely positive.  Firefox reports them as "sno File" and won't give me
> an option to display them, only to download them and/or to associate them
> with an application.
>
> Why is Fossil reporting things so differently for .sno files over .m files

Because it does not know about .sno files.
Even reporting .m as text/html is bogus, obviously. The built-in table
shows it should be assigned text/plain, however.

> and how do I get it to stop?

Patch fossil. AFAICT this is not configurable.

Alternatively, install a firefox extension that allows viewing files
in firefox. Unlike some other browsers Firefox is quite asinine wrt
mime types and refuses to show anything that is not of one of the few
viewable types it has hardcoded somewhere.

HTH

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] templates (WAS: Re: The future of markdown-in-fossil(

[Michal Suchanek]

On 3 August 2012 15:39, Stephan Beal  wrote:
> On Fri, Aug 3, 2012 at 3:22 PM, Michal Suchanek  wrote:
>>
>> When user HTML templates are implemented it will be possible to store
>> in the HTML template, presumably as part of configuration that can be
>> replicated along with the repository content.
>
>
> Correct. The initial implementation "might not" be directly syncable, but
> that is the long-term plan. If we decide to use in-filesystem templates
> (like the embedded docs, basically) then they would sync automatically. But
> we also need a mechanism which prohibits the import of malicious templates
> via syncronization, so this detail has to be considered carefully (input is
> of course welcomed).

And how do you prevent malicious code import through synchronization?

This is the exact same thing. Either you don't import or don't use
what you import or you are vulnerable to what you import.

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] usability of in-project documentation

[Michal Suchanek]

On 3 August 2012 14:45, Stephan Beal  wrote:
> On Fri, Aug 3, 2012 at 11:48 AM, Michal Suchanek
>>
>> I am not opposed to writing patches, and all these issues are quite
>> trivial but I am also aware that some patches are rotting in the
>> fossil tickets for years so I guess patches are not what gives you
>> fixed fossil.
>
>
> i suspect the main problem there is that fossil lacks triggers/email
> notifications (for portability reasons), and if the ticket doesn't get
> noticed in the first page of the timeline view (the first 20 entries) then
> it probably goes unnoticed more often than not.
>

Another problem is that fossil needs a contributor agreement so random
patches attached to the tickets are not going to make it into fossil.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 15:14, Remigiusz Modrzejewski  wrote:
>
> On Aug 3, 2012, at 14:57 , Stephan Beal wrote:
>
>> That said: in several of my fossil wikis i store Google Code format in the
>> wiki and render it client-side. My only point there is that it _is_
>> currently possible to integrate any wiki format(s) you want to as long as
>> you can render them client-side, and if you are using multiple formats you
>> need a way of differentiating them (so you know which rendered to use),
>> e.g. via a naming convention or a special markup tag in the first line, or
>> similar.
>
> Is it possible to bundle this solution into a single binary like the original 
> Fossil?

In current fossil you would have to patch the JavaScript code into the
HTML template that is in the fossil code and rebuild fossil. This is
obviously problematic because  you will have to provide binaries for
all platforms you want to support.

When user HTML templates are implemented it will be possible to store
in the HTML template, presumably as part of configuration that can be
replicated along with the repository content.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 14:40, Konstantin Khomoutov
 wrote:
> On Fri, 3 Aug 2012 12:19:01 +0200
> Michal Suchanek  wrote:
>
>> >> Why markdown and not one of the dozens of other wiki syntaxes?
>> >
>> > Because markdown is a very popular one, used by github, and we have
>> > on board the creator of a major implementation (the one used by
>> > github, iirc).
>>
>> The others are also very popular.
>>
>> Github has a cute logo but I would not turn to it when looking for
>> sound technical solutions.
> Stackoverflow and all the sites under its umbrella, and all the sites
> using this engine, use (modified) markdown syntax [1], [2].

So again a somewhat slightly incompatible variation.

And there are many using moinmoin or similar syntax, and many using
bbcode, and there are probably others in wide use already.

>
> I, for one, while not being a special fan of markdown syntax (to me, the
> best sytnax I ever had to deal with was that used by wiki.tcl.tk), still
> think that the proliferation of wiki markups place everyone in position
> where one just can pick a syntax to use almost at random.

And for fossil it has been picked already.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 14:02, Natacha Porté  wrote:
> Hello,
>
> on Friday 03 August 2012 at 13:41, Michal Suchanek wrote:

>> I have strong objections about all such makups, none is perfect, all
>> have some annoyances, and they are all mutually incompatible.
>>
>> Changing from one to another does not improve things, however. It only
>> brings incompatible repositories into existence.
>
> You're going much further than I am here. What I have proposed does not
> introduce any incompatibility at all. I have only included the markdown
> engine and used it for inline ("embedded doc") rendering of .mkd and
> .markdown files in the repository.
>
> As I have said elsewhere, I'm not clever enough to imagine a solution to
> introduce markdown into fossil's internal wiki. So I don't propose it. I
> propose the extra embedded doc rendering, and the tools to perform any
> markdown-to-html conversion. When someone comes up with a way to deal
> with the internal wiki, they will have such tools.

Well, then it is less than satisfactory solution.

HTML is formatted in the browser. Hence support for HTML documents
comes for free, with no code required. It is passed through as any
other file type.

The fossil wiki syntax is used in tickets and internal wiki anyway so
documents in that syntax come nearly for free. The only concern is
proper hyperlink resolution so that you can browse the site. Users
need to know the format for the tickets and internal wiki anyway, and
you have cut&paste between docs and and wiki and tickets.

Now enter .mkd files. They need additional code to parse, there is no
such nice integration with the rest of the fossil, and they do not
solve the issue of "I am not familiar with this" for the users
familiar with the other formats.

And given somebody wrote a bbcode parser implementation, moin moin
parser implementation, and a half dozen others which will be allowed
in the fossil proper? Or is parser for any random format to be added?
How large will fossil then become? Who will maintain all this? Is the
parser to be removed again when the original author is no longer
interested and no other maintainer for it steps up?

>> As you did not include a link to your repository of markdown enabled
>> fossil I cannot tell how it addresses compatibility.
>
> I did. In the very first post of this thread.

Sorry, only saw some replies, not the starting post.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 13:04, Natacha Porté  wrote:
> Hello,
>
>> > On Aug 3, 2012, at 11:53 , Michal Suchanek wrote:
>> >> Why markdown and not one of the dozens of other wiki syntaxes?
>
> If I understand correctly this question wasn't addressed to me (as a
> developer of the markdown-in-fossil code) but I'll try to contribute as
> objectively as I can.
>
> As a user, the killer feature I see for markdown is that the
> implementation exists (assuming my code is considered worthy, which is
> quite a strong assumption, but without it everything else is moot
> anyway, so I'll keep the assumption in this e-mail). Code that exists
> wins over code that does not. We can discuss for days about the best
> markup syntax, it's completely useless when there is nobody to actually
> implement it.

By the extension of this very argument, code that exists in-tree beats
code that exists out of tree. So the current syntax wins.

>
> Of course, I would welcome other propositions of implementation, and I
> would still be glad if my code was rejected in favor of another
> implementation (of markdown or of another lightweight markup language
> that I prefer to the current wiki syntax).
>
> Now my personal opinion about markdown is probably of no interest to
> anybody else, but while I do have strong objections and dislikings
> about it, I haven't encountered any other lightweight markup syntax with
> which I have more affinity. Useless, isn't it?

I have strong objections about all such makups, none is perfect, all
have some annoyances, and they are all mutually incompatible.

Changing from one to another does not improve things, however. It only
brings incompatible repositories into existence.

I have looked up the markdown syntax on wikipedia and while it removes
some annoyances of the more traditional wiki syntaxes like moinmoin or
mediawiki it can do that only at the cost of mutual incompatibility.

Interestingly, being a github user I am not familiar with the markdown
syntax although github supposedly uses it. Admittedly I have used more
moinmoin wikis, mediawikis, and phpbbs than githubs, both in total and
each separately.

Consider bbcode, too. It is not only familiar to developers but it is
even more ancient and more widespread than any wiki syntax, and many
non-developers use it.

And all of these markups are mutually incompatible. Unless you are
willing to implement a plugin engine with plugins for 3-4 most
widespread markups there is no way to really improve over what there
is now. You will also have to change the format of the database so
that it contains an additional field for text artifacts like tickets
so that they can be rendered with the correct plugin.

>
>
>
> on Friday 03 August 2012 at 12:19, Michal Suchanek wrote:
>> And it has been said that markdown is out of the scope of Fossil.
>
> I don't know about that. And honestly, I'm glad I don't have to make
> that call.
>
>>   I am
>> not to decide that but I have to agree. Once you let in markdown
>> people used to some other wiki syntax would argue they have needlessly
>> hard time and there would be no end to the stream of requests to
>> include yet another.
>
> I think it's very useful to distinguish between requests to write code in
> order to include yet another, and requests to officially mirror a branch
> containing ready-to-use code that includes yet another.
>
> Surely the stream of the second kind of requests would be much lighter
> than the stream of the first kind, wouldn't it?
>
> And as far as requests of the second kind goes, if the code is good
> enough and does not bloat the project, why not accept them? (in the
> context that assumes markdown has already been let in)

Because of compatibility with existing repositories that use the
current syntax which is not compatible with markdown.

As you did not include a link to your repository of markdown enabled
fossil I cannot tell how it addresses compatibility.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 12:26, Remigiusz Modrzejewski  wrote:

 Note there are JavaScript hacks for interpreting random wiki syntax so
 you can have markdown interpreted without any direct support in
 fossil.
>>>
>>> Note there are good wiki engines out there, so no need for one in Fossil 
>>> too. But once we set the scope to include something, please don't keep it 
>>> half-hearted...
>>
>> And it has been said that markdown is out of the scope of Fossil. I am
>> not to decide that but I have to agree. Once you let in markdown
>> people used to some other wiki syntax would argue they have needlessly
>> hard time and there would be no end to the stream of requests to
>> include yet another.
>
>
> I've read the "we'll have requests for all the markups in the world" argument 
> many times. I can't remember anyone actually coming and asking for *anything* 
> else than markdown.

That may also prove only that markdown proponents are noisy and inconsiderate.

Project X should have markdown because it is what I am familiar with
and it seems to me the best and most widespread syntax, meh.

Regards

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 12:07, Remigiusz Modrzejewski  wrote:
>
> On Aug 3, 2012, at 11:53 , Michal Suchanek wrote:
>
>> On 3 August 2012 11:23, Remigiusz Modrzejewski  wrote:
>>> +1
>>
>> Why markdown and not one of the dozens of other wiki syntaxes?
>
> Because markdown is a very popular one, used by github, and we have on board 
> the creator of a major implementation (the one used by github, iirc).

The others are also very popular.

Github has a cute logo but I would not turn to it when looking for
sound technical solutions.


>
>> I don't find wiki syntaxes really easy. Maybe a bit easier to type
>> than HTML but definitely not easy to read or remember, especially
>> since there are dozens of slightly (and not so slightly) different
>> variants.
>
> That's why half of the web seems to standarize on markdown. The same web that 
> was mostly writing HTML a few years ago.

Does not seem that way to me.

I deal with sites using various wiki format variations.

If you want to make your point on that then supply more data, please.

>
>> Note there are JavaScript hacks for interpreting random wiki syntax so
>> you can have markdown interpreted without any direct support in
>> fossil.
>
> Note there are good wiki engines out there, so no need for one in Fossil too. 
> But once we set the scope to include something, please don't keep it 
> half-hearted...

And it has been said that markdown is out of the scope of Fossil. I am
not to decide that but I have to agree. Once you let in markdown
people used to some other wiki syntax would argue they have needlessly
hard time and there would be no end to the stream of requests to
include yet another.

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] The future of markdown-in-fossil

[Michal Suchanek]

On 3 August 2012 11:23, Remigiusz Modrzejewski  wrote:
>
> On Jul 30, 2012, at 19:43 , Gautier DI FOLCO wrote:
>
>> 2012/7/30 Bill Burdick 
>>
>>> I'd like to see it included, as well!
>>
>>
>> I'd like it too, it will be easier for beginnes (like me!).
>
> +1

Why markdown and not one of the dozens of other wiki syntaxes?

I don't find wiki syntaxes really easy. Maybe a bit easier to type
than HTML but definitely not easy to read or remember, especially
since there are dozens of slightly (and not so slightly) different
variants.

Note there are JavaScript hacks for interpreting random wiki syntax so
you can have markdown interpreted without any direct support in
fossil.

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] usability of in-project documentation

[Michal Suchanek]

hello,

while the wiki has its entry in the fossil menu and is easy to find
the in-project documentation is not so obvious.

As a fossil user I have to read the manual to find the docs at all so
I would know. The manual is even quite well explained and almost
exhaustive.

However, if I were to direct people to the in-project docs who are not
seasoned fossil users themselves I can envision quite a few problems.

Firstly, fossil has undocumented index file support, and the index
file name is hardcoded in the fossil source. Interestingly, this index
file is index.html (only). Having checked index.wiki or README or
readme.txt into the repository is no use. You will have to use an
index.html with redirect to have one of those files as index.

Second, the doc/ hierarchy behaves very odd compared to what users
would expect after visiting sites served by other we servers.

The url http://www.fossil-scm.org/fossil/doc contains: No such
document: index.wiki

This is very misleading. I have no idea where this comes from as
1) there is no possibility that any files reside on this URL
2) index.wiki is not index file of anything

I guess if this page was to contain useful content it could redirect
to tip or other configurable branch or just list branches (and include
ckout in the list when an open repository is served).

The url http://www.fossil-scm.org/fossil/doc/trunk contains: No such
document: index.html
This is more to the point since it complains about non-existence of
the undocumented index file. However, if the file did exist and was
served through this url it would necessarily have broken links. Or the
links would be broken when served through
http://www.fossil-scm.org/fossil/doc/trunk/ or
http://www.fossil-scm.org/fossil/doc/trunk/index.html because the
latter urls are down one directory in the url hierarchy. Redirection
to single URL is required for such file to work.

The url http://www.fossil-scm.org/fossil/doc/www again complains about
the missing index file. In the current fossil release it would
complain that www does not exist, and only allow
http://www.fossil-scm.org/fossil/doc/www/

I also notice that while the CSS is customizable the HTML templates
are not. While this is not much of a problem for many projects in some
cases you would want to reorganize the page layout and/or add
additional elements. At the very least adding some more divs off which
to hang the style rules would be useful.
eg. I was considering to add a background to the page header but
noticed that by default the body has 1ex margin which prevents the
header background from reaching the sides of the page. Removing this
margin starts a cascade of changes required to return to remotely sane
formatting while stylistic-only header and content div which
implements the margin and possibly background in place of the body
element would work wonderfully.

Is there any chance that the in-repo doc serving is polished at least
to the point that it's usable by unsuspecting people just browsing the
web without realizing this is in fact a fossil repository. As it is
the fossil served pages need to be used very carefully because they
are quite fragile compared to what you would expect from, say, static
directory structure served off apache.

I am not opposed to writing patches, and all these issues are quite
trivial but I am also aware that some patches are rotting in the
fossil tickets for years so I guess patches are not what gives you
fixed fossil. I can apply them locally but it does not help if I want
other people to be able to mirror my repo or use chiselapp, or
whatever. And I need to rebuild for every architecture myself since
whatever official packages exist will never get my local patches.

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] Why you should not shun

[Michal Suchanek]

On 6 October 2011 02:48, Gé Weijers  wrote:
>
>
> On Wed, 5 Oct 2011, Michal Suchanek wrote:
>
>> And when you find an issue with a commit that is some way back in your
>> personal branch it is more logical and easier to review your branch if
>> you append the fix to the commit where it belongs logically or if you
>> append it at the top of the history interspersed with some possibly
>> unrelated changes?
>
> One of the downsides of rebasing is that the following workflow does present
> problems:
>
> - develop & commit
> - sync with upstream, rebase/commit
> - test
> - sync with upstream, rebase/commit and push
>
> The version you tested now no longer exists in the repository. This may not
> be a big issue in some environments, but it may be a showstopper elsewhere
> (where I work it is).
>
> If you have to use a Git repository in such an environment you end up using
> hooks to log all updates, and block all forced updates (updates that edit
> history). Otherwise one clueless developer can do serious damage.

Most sane git workflows require that sync with upstream does not
require forced updates. Some project have experimental branch that may
but all else should update cleanly. You can always make a copy of your
branch before you rebase so that you do have a copy.

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] git vs fossil again (was: why you should not shun)

[Michal Suchanek]

On 5 October 2011 20:12, Mike Meyer  wrote:
> On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
>  wrote:
>>
>> That sort of "we don't need it, we don't need it" mantra is a typical
>> case of the famous "Blub paradox".
>> I mean, if we have two DVCS tools one of which makes you able to
>> rewrite history and another one which doesn't, the first one is more
>> powerful _in this particular respect_.  It's as simple as that.
>> By supporting a feature, the tool does not force you to employ that
>> feature in your workflow.
>
> First,  note that there is a difference between "rewriting history", which
> is what git supports, and "deleting unwanted items", which is the request
> that started this.
> Second, that a feature doesn't affect you if you "just don't use it" is a
> fallacy. Sure, I think history should be sacrosanct, so I won't use rebase
> even if it's available. That doesn't stop others on the project (who  don't
> agree with me) from using it . The only way to make sure that doesn't happen
> is to not have the feature available *at all*.

No, that's not how things work.

Rebase is nothing more than taking commits comprising a branch from
its branching point and applying them somewhere else. Not that
complicated, really.

As applying patches is doable, even patches stored in fossil history
already, this is doable with a bit of scripting around fossil as it is
doable with git. So not having the feature is not perfect defence, it
only defends against people who don't care about the feature. People
who find it useful for their workflow and want to use fossil for
compatibility with upstream of for other features it provides can do
so.

As an alternative you could use export/rebase/import which is just
different way to script this on a higher level.

>Finally, having a feature that powerful available tends to cause the API to 
>*not* include safe versions of common tasks that >that dangerous feature 
>handles. To see what I mean, take a look at mercurial, which shares the fossil 
>philosophy, but >provides a (disabled by default) rebase command. It has a 
>number of commands (*not* disabled by default) for tasks that >are handled in 
>git using rebase. Unlike rebase, those commands are safe, in that mistakes 
>with them can't wreck your repo >the way a mistake with rebase can. It may not 
>make a difference if you never make mistakes, but in that case you don't >need 
>rebase.

You can shoot yourself in the foot with any tool. Using tools that
suit your workflow makes that less likely, being dangerous or not.

I personally make a copy of any branch before rebasing it because in
the case rebasing fails you can still revert it but comparing with the
old branch makes it much clearer where you ended up.

If you never delete anything it makes your work safer but your
repository more hairy.

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] Why you should not shun

[Michal Suchanek]

2011/10/5 Lluís Batlle i Rossell :
> On Tue, Oct 04, 2011 at 02:34:06PM -0700, Mike Meyer wrote:
>> On Tue, Oct 4, 2011 at 1:50 PM, Erlis Vidal  wrote:
>>
>> > You shun a commit or a file in a commit? Is in fossil the shun generating a
>> > different commit?
>> >
>> > you can delete with git files that has history with
>> >
>> > git filter-branch --index-filter 'git rm -r --cached --ignore-unmatch
>> > file_name' HEAD
>> >
>> > and that will generate a new commit without the file you just deleted (yes
>> > I know, that git command is really cryptic that's why I'm liking fossil so
>> > much :)
>> >
>> > but I don't see how this will affect modified files. If the files are
>> > commited before, then you will never will lose those changes... unless you
>> > have shun those files, but I don't think that's the case, the file that was
>> > shun was a big image file, or I'm wrong?
>> >
>> > I don't understand, but I feel that maybe I have to learn more fossil
>> > before continue, because I have the feeling this was more a bug than a
>> > misuse of a feature.
>> >
>>
>> You've just hit on a philosophical difference between git and fossil. In the
>> fossil community - and hence in fossil itself - development history is
>> pretty much sacrosanct. The very name "fossil" was to chosen to reflect the
>> unchanging nature of things in that history.
>>
>> In git (or rather, the git community), the development history is part of
>> the published aspect of the project, so it provides tools for rearranging
>> that history so you can present what you "should" have done rather than what
>> you actually did.
>
> I use to make an analogy to open-software/closed-software, talking about
> open-development/closed-development.
>
> git looks to me as a tool for publishing development steps, not necessarily 
> very
> related to the development history. The 'git version graph' is determined by 
> the
> users the same way as they choose filenames or directories, and many git 
> groups
> even consider keeping the git graph close to development history as a 'basic 
> and
> inexpert approach' to git.

It is because it is not useful to have every *actual file edit*
recorded as commit. You often edit multiple files to perform a change,
or do some work on the project, save it, go for lunch, and then do
some more work on it.

From a totally purist point of view should the history be recorded
every time you save a file? Every time you write or delete a
character?  No, it is saved in logical pieces - commits.

And when you find an issue with a commit that is some way back in your
personal branch it is more logical and easier to review your branch if
you append the fix to the commit where it belongs logically or if you
append it at the top of the history interspersed with some possibly
unrelated changes?

You can always create a new branch and put the commits in a different
order on that branch, merging the original commit with the fixup,
start applying your local changes at a later time in the upstream
project history. Git provides more tools to make this history
rewriting easier so that the presented development steps are easier to
understand to a reviewer.

You have to find some balance between shunning all history and
recording every character typed.

I don't mind fossil keeping these dead branches. In fact, git does so
too until you manually prune the repository of unreferenced objects.
You can also select to show only live branches in fossil so the
difference is mostly cosmetical, as are all the differences between
distributed VCSes.

In one you get a command shipped as part of core, in other you can
find a dozen contributed scripts that do the same or roll your own.
It's just a matter of taste or the core tools and available scripts
being more fitting for a particular task at hand.

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] Needed: volunteer to autoconf Fossil

[Michal Suchanek]

On 15 June 2011 08:37, Alexander Vladimirov  wrote:
> how abouth this: http://buildconf.brlcad.org

A script like that is standard part of many autotoolized projects. In
fact, most people can't build an autotoolized project (other than
release tarballs with pre-generated configure that happens to work for
them) without such script present.

That does not alleviate the need to write autotools tests, keep up
with changing syntax/semantics between autotools version, etc.

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] Needed: volunteer to autoconf Fossil

[Michal Suchanek]

On 15 June 2011 09:47, Twylite  wrote:
> On 09:59 PM, Matt Welland wrote:
>> For fossil you could keep the files generated by autoconf (not the
>> ./configure step but the initialization step) checked in. Then it is
>> just ./configure && make install on most systems. For anything weird
>> (e.g. windows) provide a Makefile.win32 or similar.
> Right, so maintain multiple build systems because the one available
> out-of-the-box on your platform doesn't support one of the major target
> platforms.  In doing so, ensure that the Windows build files are never
> quite up to date, so that rather than contributing to the project
> Windows-based developers spend their time fixing build problems.

Autotools can be installed and operated on Windows like most other
build configuration systems.

BTW Microsoft ships gcc for SFU with Windows 7.

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] Needed: volunteer to autoconf Fossil

[Michal Suchanek]

On 15 June 2011 07:55, Matt Welland  wrote:
> All of these alternative build systems are a PITA on one system or another.
> If it requires jam, cmake or anything that requires installing prerequisites
> 9 times out of 10 I won't even try that software unless there is a binary
> install available somewhere or a pre-assembled Makefile.
>
> I thought that from an end user perspective all that is needed with autoconf
> is sh. The requirement is on the developer to run autoconf before making the
> tar. I thought autoconf itself is not needed on the platform where the build
> is being done, correct??

So long as you get all the tests right, yes.

However, in my experience most autotoolized projects require some
patches to random parts, and most often the auto* parts requiring the
auto* suite on the user's system.

For a long time building on OS X required regenerating the auto* parts
of pretty much everything because only fresh autotools supported it,
and scripts generated by older tools failed (and everybody used some
random old autotools). That's for an experience from slightly exotic
platform.

The alternatives usually require the configuration tool to be present
to generate *any* makefile skipping the intermediate shell script
step.

This seems like a drawback but consider that

 - in many cases when you have to build the tools in question you
would have to build autotools to regenerate the shell script anyway
 - the tools are available for most platforms anyway
 - cross-building is an option for overly uncooperative exotic platforms
 - not relying on the intermediate shell script makes maintenance and
dependency tracking easier

I would like to see, eg. platforms supported by autotools out of the
box that don't have CMake or Python.

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] Fossil - "github-in-a-box"

[Michal Suchanek]

On 12 November 2010 20:53, Jeff Rogers  wrote:
> I was recently skimming over the book 'Producing Open Source Software"
> and it suggests a set of tools that an open source project needs:
> - web site
> - mailing lists
> - version control
> - bug tracking
> - real-time chat
> (from http://producingoss.com/en/technical-infrastructure.html)
>
> Fossil already has three of these (website, vcs, bug tracking).  While I
> doubt the fossil maintainers would be interested in bloating fossil by
> adding the other two items (mailing list management and real-time chat)
> it would be an interesting project (perhaps for a hosting site) to
> create a "oss community in a box" based on fossil.  (project = fossil
> repo + proj...@hosting.site mailing list + proj...@hosting.site jabber MUC).
>

It would be a project on its own to make a ML management software that
does not suck and advertise it enough so that it is used.

Most projects these days use GNU Mailman and like fossil's its web is
broken by default and the list management functions also leave some
things to be desired.

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] Wookoo! Google Code Wiki Syntax in fossil!

[Michal Suchanek]

On 13 November 2010 11:43, Stephan Beal  wrote:
> On Sat, Nov 13, 2010 at 11:24 AM, Stephan Beal 
> wrote:
>>
>> Here's are full instructions, and they can easily be adapter to other
>> JavaScript-based wiki syntax parsers:
>
> Okay, well, almost... the parser is mis-parsing some bits which it doesn't
> mis-parse if i feed it the same day without it running through fossil.
> Apparently some bytes are getting changed in a way which is incompatible
> with the parser.
> i see now that fossil is apparently still marking up [WikiWord|links] in
> HTML, and that interferes with the parser. i figured that "all HTML" would
> disable wiki links. So formatting which doesn't generate links works, but
> fossil will still try to take over any [WikiStyle links]. That explains why
> the intra-wiki links worked with fossil, even after being run through the
> GoCo parser.
> How feasible is an option to allow 100% unprocessed wiki content?
>
>

You need to implement an option for that (or better make the current
HTML option do really HTML).

There was some discussion earlier and there are other people who would
welcome true HTML in fossil.

I would welcome a true wiki with formatting features on par with
MediaWIki or markdown but that's another thing.

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] Way of submitting fossil patches so that they get looked at?

[Michal Suchanek]

Hello

I have submitted patches for tickets

53aa95f382289c25ee847521762edbe7e5da768e
0e5d75657faa7a7cefb3ba8546d2b377e8bee4ed
1ec8be0c5332ef57cf4dbe1b3e96fe25ca4ddf00

some time ago and they were neither accepted nor is there any reason
stated why they are unacceptable.

I also submitted patch for ticket

727af73f467a64be0d0bbbcf46c513062a9e4704

Can somebody look at the ticket patches?

Should they be submitted elsewhere?

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] SSL support?

[Michal Suchanek]

On 3 November 2010 13:01, Richard Hipp  wrote:
>
>
> On Wed, Nov 3, 2010 at 5:20 AM, Michal Suchanek  wrote:
>>
>> Helllo
>>
>> I tried building fossil trunk (with a few patches) and when I try to
>> commit fossil says:
>>
>> Autosync:  https://
>>
>> fossil: HTTPS: Fossil has been compiled without SSL support
>>
>> I clearly see
>>
>> gcc -g -Os -Wall -DFOSSIL_ENABLE_SSL  -I. -I./src -o ./obj/http.o -c
>> http_.c
>>
>> Is SSL no longer supported or is there some issue currently?
>
> Works fine for me here on Linux and Mac.  Are you sure you are running the
> correct binary?
>

Yes, the issue was that I used the included script to build a Debian
package and installed that. The resulting package was empty and
another old binary was used instead.

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] SSL support?

[Michal Suchanek]

Hello

I am running fossil trunk with a few local patches and whenever I try
to commit I get:

Autosync:  https://
Bytes  Cards  Artifacts Deltas
Send: 130  1  0  0
fossil: HTTPS: Fossil has been compiled without SSL support


Is SSL still not supported?

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] SSL support?

[Michal Suchanek]

Helllo

I tried building fossil trunk (with a few patches) and when I try to
commit fossil says:

Autosync:  https://

fossil: HTTPS: Fossil has been compiled without SSL support

I clearly see

gcc -g -Os -Wall -DFOSSIL_ENABLE_SSL  -I. -I./src -o ./obj/http.o -c http_.c

Is SSL no longer supported or is there some issue currently?

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] filename contains illegal characters

[Michal Suchanek]

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?

The only characters a filename cannot not contain are / and \0. On
windows there are some more and there are some reserved filenames
carried over from DOS. . and .. have special meaning, that's all
right.

On the other hand while [] and *? can be expanded under some
circumstances so can {} () <> $ # @ ~ & | ; and whatnot but all can be
part of a filename.

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] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 26 June 2010 23:47, Owen Shepherd  wrote:
> On 26 June 2010 20:59, Michal Suchanek  wrote:
>>

>>>>>
>>>>> SCSU is of course a poor choice for an in-memory format (Use UTF-16)
>>>>> or interacting with the console (For backwards compatibility you're
>>>>> probably going to have to use UTF-8). But for a storage format,
>>>>> particularly one embedded within a database? It's pretty much perfect.
>>>>
>>>> Anybody who suggests to use UTF-16 for anything has no idea about
>>>> useful encodings in my book. UTF-16 has no advantage whatsoever, only
>>>> disadvantages.
>>>
>>> Would you care to enumerate your points then?
>>>
>>
>> UTF-8 is endianness independent and null-free, UTF-16 is not. In
>> transport losing a byte (or a packet with unknown, possibly odd number
>> of bytes) may corrupt at most one character of UTF-8, it may misalign
>> the whole stream of UTF-16.
>
> I said UTF-16 /in memory/. Not for transport. Whole different kettle of fish
>
>> UTF-32 is dword aligned, you can index into it as an array and every
>> position is a codepoint. UTF-16 has surrogate pairs so you have to
>> decode the whole string to get at codepoints.
>
> You rarely need to index into it at code-point intervals. For most things
> pointers are sufficient
>
> And you should note that dword is a rather vague term; I somehow
> presume you are referring to the x86' 32-bit double word (Which is not
> even consistent in x86 documentation - the i386 SysV ABI used by all
> unixlikes takes a word to be 32-bits).
>
> (I could also mention that every index in a UTF-16 string is also
> technically a codepoint, but lets not get into a battle of semantics;
> the correct term for what you are referring to is a scalar value).

Well, it isn't any more than it is in UTF-8. Some braindead runtimes
expected that the (16bit) word in UTF-16 actually is a codepoint and
had to be fixed later, and there are issues with legacy code which
still expects the old behaviour.

It may be that on many CPUs it is more time efficient if the branch
which reads more than once from the string to get the codepoint is
executed rarely but then the ultimate efficiency is achieved with
UTF-32 which is 32-bit aligned which is by far the fastest on most
CPUs and needs no branching at all at this level. Also for short
strings reduced code complexity outweights any savings by string
compression by using more space-efficient encoding.

>
>> I know no language for which UTF-16 is storage-efficient. For
>> languages using Latin UTF-8 or legasy encodings are about twice as
>> efficient. For Cyrrilic legacy encodings are much more efficient, I
>> don't know how UTF-16 compares to UTF-8 here. For CJK UTF-16 is about
>> 2/3 of UTF-8 but more efficient alternative encodings exist and are in
>> widespread use.
>
> Said more efficient alternative encodings are not Unicode and should
> not be considered a serialization of such. An endemic problem with
> using them as such is that some have mapped characters over the ASCII
> common set - a prime example being that Shift-JIS replaced the
> backslash with a Yen. Those legacy encodings also often require
> complex string search logic (Shift-JIS again being a prime example).
>
> For Chinese, the recommended backwards-compatible encoding is GB
> 18030. This is a good effort but flawed (Decoding it is an absolute
> nightmare), and should be converted to a more usable (e.g. UTF-16)
> format for in memory use.

These are not Unicode, they are developed for Japanese and Chinese,
respectively.

And I don't see why you promote SCSU which maps just about anything
over ASCII and has shifts yet you bash SJIS for mapping Yen over
backslash and having shifts. There is an issue with legacy software
using Yen instead of backslash but that is not an issue with the
encoding itself, it's an issue with how it is abused. It's still a
valid reason to avoid the encoding since it makes the semantics of
these incorrectly used codes ambiguous.

Now SCSU might be easier to decode which makes the required code
smaller in comparison to other encodings but SCSU is not widely
supported and would require constant recoding from the system encoding
and web encoding which inflates the required code again.

>
>> If you know any advantage of UTF-16 then please enlighten me.
>
> UTF-16 is very efficient to work with. Its for this reason that many
> languages which adopted Unicode post the expansion of the coding space
> still picked it (Python for one). It is an effective tradeoff of space
> and speed.

I don't see the efficiency. It's an approach in the middle which does
not r

Re: [fossil-users] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 26 June 2010 18:05, Owen Shepherd  wrote:
> On 26 June 2010 13:47, Michal Suchanek  wrote:
>> On 25 June 2010 21:37, Owen Shepherd  wrote:
>>> On 25 June 2010 19:36, Michal Suchanek  wrote:
>>>> On 25 June 2010 20:18, Owen Shepherd  wrote:
>>>>> One of the reasons that I'm a fan of SCSU is that, with even a
>>>>> relatively simple encoder, it produces output which is comparable in
>>>>> efficiency to that of most legacy encodings.
>>>>
>>>> SCSU is a horrendous encoding because it uses shifts. When the shift
>>>> is lost the text has completely different meaning. In UTF-8 if you
>>>> remove part of the text only that part is affected (if you cut
>>>> mid-character you create a bad character at worst but it can be
>>>> clearly detected).
>>>
>>> And how often do you lose a couple of bytes in the middle of a file?
>>> More precisely, how often do you lose them and not have a checksum
>>> fail (or some other error) notifying you of this?
>>
>> If the file is a web page then quite often, and it does not have a checksum.
>
> In that case I'd have to question the quality of your networking
> equipment and software. Losing a couple of bytes in the middle of a
> web page is something that should not be possible under TCP (Unless,
> perhaps, one is under attack from a malicious 3rd party, in which case
> a bit of data loss is the least of your worries).

Indeed, the loss is at the end in case of web pages, parts which are
missing in the middle are result of inserting different streams so
SCSU would not suffer more breakage than other encodings. Still there
is no apparent benefit in using it.

>
> And HTML is also a file format with the equivalent of shifts; it just
> calls them tags.

However, most HTML parsers are very well capable of parsing incomplete
HTML because the tags don't change the meaning of text except when it
is part of tag attribute.

>>>
>>> SCSU is of course a poor choice for an in-memory format (Use UTF-16)
>>> or interacting with the console (For backwards compatibility you're
>>> probably going to have to use UTF-8). But for a storage format,
>>> particularly one embedded within a database? It's pretty much perfect.
>>
>> Anybody who suggests to use UTF-16 for anything has no idea about
>> useful encodings in my book. UTF-16 has no advantage whatsoever, only
>> disadvantages.
>
> Would you care to enumerate your points then?
>

UTF-8 is endianness independent and null-free, UTF-16 is not. In
transport losing a byte (or a packet with unknown, possibly odd number
of bytes) may corrupt at most one character of UTF-8, it may misalign
the whole stream of UTF-16.

UTF-32 is dword aligned, you can index into it as an array and every
position is a codepoint. UTF-16 has surrogate pairs so you have to
decode the whole string to get at codepoints.

I know no language for which UTF-16 is storage-efficient. For
languages using Latin UTF-8 or legasy encodings are about twice as
efficient. For Cyrrilic legacy encodings are much more efficient, I
don't know how UTF-16 compares to UTF-8 here. For CJK UTF-16 is about
2/3 of UTF-8 but more efficient alternative encodings exist and are in
widespread use.

If you know any advantage of UTF-16 then please enlighten me.

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] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 25 June 2010 21:37, Owen Shepherd  wrote:
> On 25 June 2010 19:36, Michal Suchanek  wrote:
>> On 25 June 2010 20:18, Owen Shepherd  wrote:
>>> One of the reasons that I'm a fan of SCSU is that, with even a
>>> relatively simple encoder, it produces output which is comparable in
>>> efficiency to that of most legacy encodings.
>>
>> SCSU is a horrendous encoding because it uses shifts. When the shift
>> is lost the text has completely different meaning. In UTF-8 if you
>> remove part of the text only that part is affected (if you cut
>> mid-character you create a bad character at worst but it can be
>> clearly detected).
>
> And how often do you lose a couple of bytes in the middle of a file?
> More precisely, how often do you lose them and not have a checksum
> fail (or some other error) notifying you of this?

If the file is a web page then quite often, and it does not have a checksum.

If the encoding is intended solely for storage then anything that is
easy to work with would do and SCSU does not seem to particularly
shine in that area, not compared to more well-known and widespread
encodings for which tools are more readily available.

>
> It's a particularly egregious complaint in the context of Fossil -
> where all records are hashed anyway! Additionally, if the same kind of
> error were to occur to the SQLite file that the repository is
> contained within, it would probably be trashed irretrievably.
>
> Years of experience with binary and other modal file formats (XML and
> HTML to name two very common) show that this is a complete non-issue.

It is not an issue if the partial data still makes sense which is not
the case with SCSU shifts which completely change the meaning of the
rest of the data.

>
> SCSU is of course a poor choice for an in-memory format (Use UTF-16)
> or interacting with the console (For backwards compatibility you're
> probably going to have to use UTF-8). But for a storage format,
> particularly one embedded within a database? It's pretty much perfect.

Anybody who suggests to use UTF-16 for anything has no idea about
useful encodings in my book. UTF-16 has no advantage whatsoever, only
disadvantages.

SCSU is not that useful for storage compression since fossil already
uses zlib and it has no other advantages I am aware of.

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] May fossil push via ssh?

[Michal Suchanek]

On 25 June 2010 12:16, Ruslan Popov  wrote:
> Hi,
>
> May fossil push via ssh?
>

Not the way you are used to I guess. You can start a fossil server and
create a ssh tunnel to it and then use the HTTP push. Or you can use
sshfs.

HTH

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] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 25 June 2010 20:18, Owen Shepherd  wrote:
> One of the reasons that I'm a fan of SCSU is that, with even a
> relatively simple encoder, it produces output which is comparable in
> efficiency to that of most legacy encodings.

SCSU is a horrendous encoding because it uses shifts. When the shift
is lost the text has completely different meaning. In UTF-8 if you
remove part of the text only that part is affected (if you cut
mid-character you create a bad character at worst but it can be
clearly detected).

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] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 25 June 2010 18:09, Owen Shepherd  wrote:
> The trouble is that UTF-8 is a poor standard. It bloats many texts, is
> quite expensive to parse, and has only one redeeming feature: It never
> creates embedded nulls. I suppose that it shares its encoding with
> ASCII is a feature too, but only a minor one.
>
> Personally, I think that most systems should adopt SCSU as their
> storage encoding, but that's unlikely to happen until C strings and
> MIME (two paragons of awfulness) die out.
>
> On 25 June 2010 16:00, Michael Richter  wrote:
>> On 25 June 2010 21:34, Michal Suchanek  wrote:
>>>
>>> Perhaps fossil should have a "system encoding" which it would get from
>>> the environment (locales, windows codepage) and mark all commit
>>> messages with it.
>>
>> I vote that this is an extraordinarily bad idea.
>> Fossil is a distributed SCM system.  Potentially the distributed database in
>> question could be spread around the world.  Do you really want the nightmare
>> (and impossibility!) of trying to keep track of which project is in which
>> encoding scheme on which machine?  UTF-8 is a standard explicitly designed
>> to stop this kind of confusion.  It's also been around since 1993, so your
>> development tools have had plenty of time to catch on and actually use it.

The fact is that Windows is a supported platform and on Windows common
tools do not use UTF-8 for good or for bad. So there should at least
be the code to identify the system encoding and convert it to the repo
encoding.

Also note that UTF-8 and Unicode in general is not the encoding of
choice for CJK languages for various reasons. I guess it is acceptable
to convert from the system ancoding to UTF-8 on a best-effort basis
(which usually causes minimal loss of information if any) so that the
repository commit messages and other texts shown on the web can be
merged together without resorting to iframes or other similar
atrocities.

The tracked files themselves are, of course, free to be in any
encoding. Still displaying files in arbitrary encoding on an UTF-8 web
app is somewhat troublesome so it would be an advantage to have the
possibilty to start a repo in different encoding or to switch the web
encoding so that files in different encodings can be viewed easily.
Tagging the files with an encoding when they are interpreted as text
by fossil would be also useful.

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] Mix of UTF-8 and CP1251 (Russian cyrillic) in project

[Michal Suchanek]

On 25 June 2010 12:15, Sergey Sfeli  wrote:
> Ruslan Popov wrote:
>
>> I've tried to use Fossil on russian version of Windows 7. I made commit with
>> russian text in comment, when I run the UI and look at timeline, I saw that
>> russian text looks like squares.
>
> Why don't just use text editor that supports UTF-8 and write your
> comments in UTF-8 instead of cp1251? You can set/change default text
> editor with "fossil set editor anything-else-than-notepad" (I am using
> Notepad2, for example).
>
>
> Question to Richard Hipp: can you please add any UTF-8 character(s) to the
> following text to help text editors to auto-detect the right encoding?
>
> # Enter comments on this check-in.  Lines beginning with # are ignored.
> # The check-in comment follows wiki formatting rules.
>

Perhaps fossil should have a "system encoding" which it would get from
the environment (locales, windows codepage) and mark all commit
messages with it.

This should mark the commits with the correct encoding on most
unix-like systems. On windows there is a "DOS codepage" and a "Windows
codepage" so there is no completely reliable way of determining the
encoding used on the system although the "Windows codepage" would be
what most windowed programs use. Still there should be a possibility
to set the encoding explicitly.

It is somewhat open question what to do when displaying timeline of a
repository with commits in multiple encodings, though.

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] Place to post patches?

[Michal Suchanek]

On 17 June 2010 16:07, Richard Hipp  wrote:
>
>
> On Thu, Jun 17, 2010 at 10:02 AM, Michal Suchanek 
> wrote:
>>
>> Hello
>>
>> Is there a good place for posting fossil patches?
>>
>> There are a few which I posted here a while ago. One got some replies
>> but the others are just archived in the ML and aging.
>>
>> There is no way to attach files (including patches) to bug reports so
>> that they won't get forgotten.
>>
>
> I have just now turned on the permission for anonymous users to attach files
> to tickets and wiki pages.
>

Added the patches to the respective tickets.

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] Place to post patches?

[Michal Suchanek]

Hello

Is there a good place for posting fossil patches?

There are a few which I posted here a while ago. One got some replies
but the others are just archived in the ML and aging.

There is no way to attach files (including patches) to bug reports so
that they won't get forgotten.

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] Use redirect instead of serving index.wiki for /doc

[Michal Suchanek]

Hello

This is a fix for the /doc url.

Currently the /doc/tip/index.wiki file is served for the /doc url but
the links are not adjusted so the file has broken links if served from
/doc

ie if you have

Topic1

in index.wiki the link would not work if index.wiki is served as /doc
because there is no /doc1.wiki

This patch uses redirect instead which avoids the problem.

It also redirects /doc/ to /doc/tip/index.wiki which would return an
error previously.

The redirect is still not configurable.

Thanks

Michal
Index: src/doc.c
===
--- src/doc.c
+++ src/doc.c
@@ -308,10 +308,14 @@
 }
   }
   return "application/x-fossil-artifact";
 }
 
+static void doc_index_redirect(void){
+db_end_transaction(0);
+cgi_redirectf("%s%s", g.zBaseURL, "/doc/tip/index.wiki");
+}
 /*
 ** WEBPAGE: doc
 ** URL: /doc?name=BASELINE/PATH
 ** URL: /doc/BASELINE/PATH
 **
@@ -335,13 +339,16 @@
   char zBaseline[UUID_SIZE+1];  /* Baseline UUID */
   char * reason = "document not present in the repository";
 
   login_check_credentials();
   if( !g.okRead ){ login_needed(); return; }
-  zName = PD("name", "tip/index.wiki");
+  zName = P("name");
+  if( !zName) { return doc_index_redirect(); }
   for(i=0; zName[i] && zName[i]!='/'; i++){}
+  if( ! *zName) { return doc_index_redirect(); }
   if( zName[i]==0 || i>UUID_SIZE ){
+reason = "invalid document specified";
 goto doc_not_found;
   }
   memcpy(zBaseline, zName, i);
   zBaseline[i] = 0;
   zName += i;

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

[fossil-users] CSS fix

[Michal Suchanek]

Hello

sending a patch which fixes the fossil CSS.

Currently the CSS is broken because it sets background color and not
text color which may result in some nice visual effects like white
text on white pages.

Reported as issue 53aa95f382

Thanks

Michal
Index: src/skins.c
===
--- src/skins.c
+++ src/skins.c
@@ -30,10 +30,11 @@
 @ REPLACE INTO config VALUES('css','/* General settings for the entire page */
 @ body {
 @   margin: 0ex 1ex;
 @   padding: 0px;
 @   background-color: white;
+@   color: black;
 @   font-family: "sans serif";
 @ }
 @
 @ /* The project logo in the upper left-hand corner of each page */
 @ div.logo {
@@ -222,10 +223,11 @@
 @ REPLACE INTO config VALUES('css','/* General settings for the entire page */
 @ body {
 @   margin: 0ex 0ex;
 @   padding: 0px;
 @   background-color: #fef3bc;
+@   color: black;
 @   font-family: sans-serif;
 @ }
 @
 @ /* The project logo in the upper left-hand corner of each page */
 @ div.logo {
@@ -427,10 +429,14 @@
 @ padding:0px;
 @ font-family:verdana, arial, helvetica, "sans serif";
 @ color:#333;
 @ background-color:white;
 @ }
+@ a { color: #000; }
+@ a:link { color: #000; }
+@ a:visited { color: #222; }
+@ a:hover { color: #300; }
 @
 @ /* consistent colours */
 @ h2 {
 @   color: #333;
 @ }

Index: src/style.c
===
--- src/style.c
+++ src/style.c
@@ -251,12 +251,17 @@
 @ /* General settings for the entire page */
 @ body {
 @   margin: 0ex 1ex;
 @   padding: 0px;
 @   background-color: white;
+@   color:black;
 @   font-family: sans-serif;
 @ }
+@ a { color: #31718e; }
+@ a:link { color: #31718e;}
+@ a:visited { color: #37318e; }
+@ a:hover { color: #8e3171; }
 @
 @ /* The project logo in the upper left-hand corner of each page */
 @ div.logo {
 @   display: table-cell;
 @   text-align: center;

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

[fossil-users] Patch to add /doc/idx which shows the files in the working tree which are added to the repository

[Michal Suchanek]

Hello

Here is a modification to the previous patch which introduces yet
another doc path (/doc/idx) which shows the same files as /doc/ckout
does but shows an error when the file is not yet added to the
repository (with fossil add).

Thanks

Michal
Index: src/doc.c
===
--- src/doc.c
+++ src/doc.c
@@ -315,12 +315,13 @@
 ** URL: /doc?name=BASELINE/PATH
 ** URL: /doc/BASELINE/PATH
 **
 ** BASELINE can be either a baseline uuid prefix or magic words "tip"
 ** to me the most recently checked in baseline or "ckout" to mean the
-** content of the local checkout, if any.  PATH is the relative pathname
-** of some file.  This method returns the file content.
+** content of the local checkout, if any. "idx" is the same as "ckout"
+** but shows only files already added with "fossil add".  PATH is the
+** relative pathname of some file.  This method returns the file content.
 **
 ** If PATH matches the patterns *.wiki or *.txt then formatting content
 ** is added before returning the file.  For all other names, the content
 ** is returned straight without any interpretation or processing.
 */
@@ -330,10 +331,11 @@
   int vid = 0;  /* Artifact of baseline */
   int rid = 0;  /* Artifact of file */
   int i;/* Loop counter */
   Blob filebody;/* Content of the documentation file */
   char zBaseline[UUID_SIZE+1];  /* Baseline UUID */
+  char * reason = "document not present in the repository";
 
   login_check_credentials();
   if( !g.okRead ){ login_needed(); return; }
   zName = PD("name", "tip/index.wiki");
   for(i=0; zName[i] && zName[i]!='/'; i++){}
@@ -343,24 +345,37 @@
   memcpy(zBaseline, zName, i);
   zBaseline[i] = 0;
   zName += i;
   while( zName[0]=='/' ){ zName++; }
   if( !file_is_simple_pathname(zName) ){
+reason = "filename contains illegal characters";
 goto doc_not_found;
   }
-  if( strcmp(zBaseline,"ckout")==0 && db_open_local()==0 ){
+  if( ( strcmp(zBaseline,"ckout")==0 || strcmp(zBaseline,"idx")==0 ) && db_open_local()==0 ){
 strcpy(zBaseline,"tip");
   }
-  if( strcmp(zBaseline,"ckout")==0 ){
+  if( strcmp(zBaseline,"ckout")==0 || strcmp(zBaseline,"idx")==0 ){
 /* Read from the local checkout */
 char *zFullpath;
 db_must_be_within_tree();
 zFullpath = mprintf("%s/%s", g.zLocalRoot, zName);
+if( strcmp(zBaseline,"idx")==0 && ! db_exists(
+  "SELECT 1 FROM vfile" " WHERE pathname=%Q AND deleted=0 "
+#ifdef __MINGW32__
+  "COLLATE nocase"
+#endif
+  , zName) ) {
+  reason = "file not added to the repository";
+  goto doc_not_found;
+}
+
 if( !file_isfile(zFullpath) ){
+  reason = "file not found";
   goto doc_not_found;
 }
 if( blob_read_from_file(&filebody, zFullpath)<0 ){
+  reason = "cannot read file";
   goto doc_not_found;
 }
   }else{
 db_begin_transaction();
 if( strcmp(zBaseline,"tip")==0 ){
@@ -464,11 +479,11 @@
 
 doc_not_found:
   /* Jump here when unable to locate the document */
   db_end_transaction(0);
   style_header("Document Not Found");
-  @ No such document: %h(PD("name","tip/index.wiki"))
+  @ Error: %h(reason): %h(zName)
   style_footer();
   return;
 }
 
 /*

___
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] Patch to not show files not added to repository in /doc/ckout

[Michal Suchanek]

On 26 May 2010 19:58, Eric Junkermann  wrote:
>
>> On 25 May 2010 23:38, Eric Junkermann  wrote:
>>> On Tue, May 25, 2010 at 10:10 pm, "Michal Suchanek"
>>> 
>>> wrote:
>>>> On 25 May 2010 19:59, Eric  wrote:
>>>>>
>>> ...
>>>>>
>>>>> But ckout is only available if the server is running in a local
>>>>> checkout,
>>>>> otherwise it is silently converted to tip and what you see is the
>>>>> checked-in version. You don't see uncommitted changes unless you run
>>>>> the
>>>>> server in a checkout directory tree, which sort-of implies that you
>>>>> are
>>>>> changing stuff. The main intent was to allow you to see how a set of
>>>>> doc
>>>>> files is rendered while you are still working on it. See the last
>>>>> paragraph of
>>>>>
>>>>> http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki
>>>>>
>>>>> This is NOT a bug, it is a useful feature.
>>>>>
>>>>
>>>> This is a bug, it should show uncommited files ONLY when they are
>>>> marked to be committed.
>>>
>>> "marked to be committed"? - do you mean that a "fossil add" has been
>>> done?
>>
>> Yes
>>
>>> I might work on something, and want to preview it, only to find later
>>> that
>>> it should be included as part of another file (or thrown away entirely
>>> as
>>> a bad idea).
>>>
>>>>
>>>> Otherwise what you commit differs from this preview of files you are
>>>> working on.
>>>
>>> Why shouldn't it? All I am doing is looking at a work-in-progress.
>>> No-one
>>> else is going to see it. When is this going to cause a problem?
>>
>> I am not particularly interested in how some random files in my
>> filesystem would work as fossil doc pages.
>
> They are not random files in the filesystem, they are in the checkout
> tree, where most people would be working on their project.

But most projects would also have temporary or generated files in
there so it's not preperesentative of what should be in the
repository, either.

>
>>
>> So how do I see how the files that wil be *committed* work together?
>>
>
> By looking at doc/ckout ! That's what it is for. Wanting to distinguish
> between things you have done an "add" for and things you haven't is
> pointless. The repository doesn't know about them anyway.
>
> My normal approach is to develop away in the work area without telling
> fossil anything at all, until it is time to check in, then I do a fossil
> changes and a fossil extra to see what I have actually changed, and decide
> whether I might need a partial commit. Then I can do any necessary adds,
> renames etc. followed by a re-check and then the commit. And I can look at
> doc/ckout whenever I want, and again as part of the checking process.
>
>> If this feature is for wip-wip files what is for wip files?
>
> Well, I just don't understand what you are on about, there is only one
> level of WIP, and I can see no reason for another. There is no point in

Nor do I. But our definition on WIP state differs so there is
apparently more than one.

> "what will be committed", since the repository doesn't know, you might

It does as my patch demonstrates.

> change your mind, and you might be going to do a partial commit.

Yes, and when I do change my mind I can remova/add the files and
preview them again.

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] Patch to not show files not added to repository in /doc/ckout

[Michal Suchanek]

On 25 May 2010 19:59, Eric  wrote:
>
>> Hello
>>
>> Since fossil happily serves files not added to repository in
>> /doc/ckout I fixed the issue locally to make /doc/ckout match /doc/tip
>> after the changes are committed.
>>
>> The issue is reported as 0e5d75657f
>>
>> I do not understand the fossil source well enough to make changes with
>> confidence but since this is only for reading stuff it should not
>> break anything unrelated. Also it would be nice to add meaningful
>> messages for the other cases when fetching a doc page fails.
>>
>> I tried the patch and it works for me.
>>
>> Thanks
>>
>> Michal
>
> But ckout is only available if the server is running in a local checkout,
> otherwise it is silently converted to tip and what you see is the
> checked-in version. You don't see uncommitted changes unless you run the
> server in a checkout directory tree, which sort-of implies that you are
> changing stuff. The main intent was to allow you to see how a set of doc
> files is rendered while you are still working on it. See the last
> paragraph of
>
> http://www.fossil-scm.org/fossil/doc/tip/www/embeddeddoc.wiki
>
> This is NOT a bug, it is a useful feature.
>

This is a bug, it should show uncommited files ONLY when they are
marked to be committed.

Otherwise what you commit differs from this preview of files you are working on.

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] Patch to not show files not added to repository in /doc/ckout

[Michal Suchanek]

Hello

Since fossil happily serves files not added to repository in
/doc/ckout I fixed the issue locally to make /doc/ckout match /doc/tip
after the changes are committed.

The issue is reported as 0e5d75657f

I do not understand the fossil source well enough to make changes with
confidence but since this is only for reading stuff it should not
break anything unrelated. Also it would be nice to add meaningful
messages for the other cases when fetching a doc page fails.

I tried the patch and it works for me.

Thanks

Michal
Index: src/doc.c
===
--- src/doc.c
+++ src/doc.c
@@ -330,10 +330,11 @@
   int vid = 0;  /* Artifact of baseline */
   int rid = 0;  /* Artifact of file */
   int i;/* Loop counter */
   Blob filebody;/* Content of the documentation file */
   char zBaseline[UUID_SIZE+1];  /* Baseline UUID */
+  char * reason = "document not present in the repository";
 
   login_check_credentials();
   if( !g.okRead ){ login_needed(); return; }
   zName = PD("name", "tip/index.wiki");
   for(i=0; zName[i] && zName[i]!='/'; i++){}
@@ -343,10 +344,11 @@
   memcpy(zBaseline, zName, i);
   zBaseline[i] = 0;
   zName += i;
   while( zName[0]=='/' ){ zName++; }
   if( !file_is_simple_pathname(zName) ){
+reason = "filename contains illegal characters";
 goto doc_not_found;
   }
   if( strcmp(zBaseline,"ckout")==0 && db_open_local()==0 ){
 strcpy(zBaseline,"tip");
   }
@@ -353,14 +355,26 @@
   if( strcmp(zBaseline,"ckout")==0 ){
 /* Read from the local checkout */
 char *zFullpath;
 db_must_be_within_tree();
 zFullpath = mprintf("%s/%s", g.zLocalRoot, zName);
+if( ! db_exists(
+  "SELECT 1 FROM vfile" " WHERE pathname=%Q AND deleted=0 "
+#ifdef __MINGW32__
+  "COLLATE nocase"
+#endif
+  , zName) ) {
+  reason = "file not added to the repository";
+  goto doc_not_found;
+}
+
 if( !file_isfile(zFullpath) ){
+  reason = "file not found";
   goto doc_not_found;
 }
 if( blob_read_from_file(&filebody, zFullpath)<0 ){
+  reason = "cannot read file";
   goto doc_not_found;
 }
   }else{
 db_begin_transaction();
 if( strcmp(zBaseline,"tip")==0 ){
@@ -464,11 +478,11 @@
 
 doc_not_found:
   /* Jump here when unable to locate the document */
   db_end_transaction(0);
   style_header("Document Not Found");
-  @ No such document: %h(PD("name","tip/index.wiki"))
+  @ Error: %h(reason): %h(zName)
   style_footer();
   return;
 }
 
 /*

___
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] direct wiki links for doc pages and images?

[Michal Suchanek]

On 24 May 2010 20:44, Richard Hipp  wrote:
>
>
> On Mon, May 24, 2010 at 12:40 PM, Michal Suchanek 
> wrote:
>>
>> Hello
>>
>> the .wiki doc pages can include links in brackets. However, the links
>> point to the wiki, not the doc pages.
>
> Make your links like this:   [/doc/tip/path-to-page | Text]

But that means that if I open a version of the doc other than tip
(ckout, some older version) the links would not refer to matching
versions of the other pages.

>
>>
>> While this may be adequate for some doc links in many cases one would
>> want to link to other doc pages which is somewhat tedious with full
>> HTML.
>>
>> The same applies to images I guess although there is no special syntax
>> for image inclusion I am aware of neither in wiki nor the doc pages.
>
> I just checked in a change so that the src= attribute of  is rewritten
> to include the correct path if the markup is of the form:   src="/doc/tip/path-to-image.gif">.  I tested this change in the Sandbox on
> the Fossil self-hosting repository:
> http://www.fossil-scm.org/fossil/wiki?name=Sandbox

Actually I currently use links of the form http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] direct wiki links for doc pages and images?

[Michal Suchanek]

Hello

the .wiki doc pages can include links in brackets. However, the links
point to the wiki, not the doc pages.


While this may be adequate for some doc links in many cases one would
want to link to other doc pages which is somewhat tedious with full
HTML.

The same applies to images I guess although there is no special syntax
for image inclusion I am aware of neither in wiki nor the doc pages.


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] vim syntax file for wiki pages

[Michal Suchanek]

Hello,

does anybody have a syntax file for the .wiki doc pages?

I could probably write one but it would be pointless effort if
somebody has done so already.

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] CGI issues

[Michal Suchanek]

On 20 May 2010 08:58, Stephan Beal  wrote:
> On Thu, May 20, 2010 at 2:00 AM, Michal Suchanek 
> wrote:
>>
>> I tried installing fossil as CGI on Apache 1.3 and there is some
>> difference form what is in the docs.
>>
>> Firstly I had to use a script like this:
>>
>> #!//fossil cgi
>> repository: /.fossil
>>
>> Note the cgi parameter. Without that the server would just report an
>> internal error.
>
> Is your script named something.cgi? i've sometimes had problems (on Apache
> 1.3) with the web server requiring that extension (but it is configurable).

Well, if it required the suffix it would just serve the source, right?

>
>>
>> Is the cgi feature well tested?
>
> i host more than a dozen sites with it and haven't had any problems at all.
>
>>
>> Did anybody else try with Apache 1.3? I don't have access to the
>> server logs so I am not sure what is going on when something breaks.
>
> Apache 1.3 has been obsoleted since... 8 years (April 6, 2002, according to
> Google). Perhaps it's time to change hosters?

I somewhat like this setup as it uses a central server and a bunch of
quite powerful machines that run the scripts. And I can see why they
did not upgrade the server. Apache 1.3 works, 2.0 does not offer any
additional features for CGI configurations and it is not patched to
support this setup.

Still putting the repository elsewhere is an option.

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] CGI issues

[Michal Suchanek]

Hello

I tried installing fossil as CGI on Apache 1.3 and there is some
difference form what is in the docs.

Firstly I had to use a script like this:

#!//fossil cgi
repository: /.fossil

Note the cgi parameter. Without that the server would just report an
internal error.

The other issue is that the CSS could not be downloaded from the server.

The header links to /style.css?blackwhite but the url
contains this text in red: no such file: cgi

Removing the part with ? gives the CSS. I would suspect this would
affect other pages as well but none I tried so far was affected.

Is the cgi feature well tested?

Did anybody else try with Apache 1.3? I don't have access to the
server logs so I am not sure what is going on when something breaks.

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] Inverted style for fossil

[Michal Suchanek]

Hello

Since all the fossil styles are broken and on top of that they are on
white background which sucks I have written a CSS with dark
background.

If somebody else wants such style here it is.

Note that it was evolved from one of the styles with no logo and I
probably do not use some fossil features so not all elements are
tested. At least some pages work, though, unlike with the original
styles.

Thanks
/* General settings for the entire page */
body {
  margin: 0ex 1ex;
  padding: 0px;
  background-color: #222;
  color: #aaa;
  font-family: "sans serif";
}

/* The project logo in the upper left-hand corner of each page */
div.logo {
  display: table-row;
  text-align: center;
  /* vertical-align: bottom;*/
  font-size: 2em;
  font-weight: bold;
  background-color: #707070;
  color: #ccc;
}

/* The page title centered at the top of each page */
div.title {
  display: table-cell;
  font-size: 1.5em;
  font-weight: bold;
  text-align: left;
  padding: 0 0 0 10px;
  color: #ccc;
  vertical-align: bottom;
  width: 100%;
}

/* The login status message in the top right-hand corner */
div.status {
  display: table-cell;
  text-align: right;
  vertical-align: bottom;
  color: #bbb;
  font-size: 0.8em;
  font-weight: bold;
}

/* The header across the top of the page */
div.header {
  display: table;
  width: 100%;
}

/* The main menu bar that appears at the top of the page beneath
** the header */
div.mainmenu {
  padding: 5px 10px 5px 10px;
  font-size: 0.9em;
  font-weight: bold;
  text-align: center;
  letter-spacing: 1px;
  background-color: #404040;
  color: #bbb;
}

/* The submenu bar that *sometimes* appears below the main menu */
div.submenu {
  padding: 3px 10px 3px 0px;
  font-size: 0.9em;
  text-align: center;
  background-color: #606060;
  color: #ccc;
}
div.mainmenu a, div.mainmenu a:visited, div.submenu a, div.submenu a:visited {
  padding: 3px 10px 3px 10px;
  text-decoration: none;
}
div.mainmenu a, div.mainmenu a:visited {
  color: #ccc;
}
div.submenu a, div.submenu a:visited {
  color: #ddd;
}
div.mainmenu a:hover, div.submenu a:hover {
  color: #404040;
  background-color: #bbb;
}

/* All page content from the bottom of the menu or submenu down to
** the footer */
div.content {
  padding: 0ex 0ex 0ex 0ex;
}
/* Hyperlink colors */
div.content a { color: #ccc; }
div.content a:link { color: #ccc;}
div.content a:visited { color: #bbb; }

/* Some pages have section dividers */
div.section {
  margin-bottom: 0px;
  margin-top: 1em;
  padding: 1px 1px 1px 1px;
  font-size: 1.2em;
  font-weight: bold;
  background-color: #404040;
  color: white;
}

/* The "Date" that occurs on the left hand side of timelines */
div.divider {
  background: #383838;
  border: 2px #505050 solid;
  font-size: 1em; font-weight: normal;
  padding: .25em;
  margin: .2em 0 .2em 0;
  float: left;
  clear: left;
}

/* The footer at the very bottom of the page */
div.footer {
  font-size: 0.8em;
  margin-top: 12px;
  padding: 5px 10px 5px 10px;
  text-align: right;
  background-color: #404040;
  color: #ccc;
}

/* The label/value pairs on (for example) the vinfo page */
table.label-value th {
  vertical-align: top;
  text-align: right;
  padding: 0.2ex 2ex;
}
___
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] Internal hyperlinks, content-type and stuff

[Michal Suchanek]

On 19 May 2010 20:27, Eric  wrote:
>
>> Hello
>>
>> I considered to use fossil for my project but the curernt release is
>> unusable for me.
>>
>> I could not find any way for fossil to store non-text files and serve
>> them over http with the correct content-type, either inferred by some
>> magic or specified manually.
>>
>> As I would like to use illustrations/diagrams/pictures in the
>> documentation which I hoped to store in the included wiki there is no
>> way to do that with fossil.
>>
>> A somewhat different issue is easy linking to wiki attachments and/or
>> SCM objects in the docs. Since the artifacts are technically immutable
>> just linking to the artifact directly should suffice in most cases as
>> the link should not change over time but it would be nicer if there
>> was a way to generate links relative to the repository location so
>> that the links work also when the repository is moved to another
>> location.
>>
>> Another question is how to reliably link to a particular version vs
>> latest version of a file which is managed by fossil.
>>
>> As the wiki formatting page does not answer these question I suspect
>> fossil only relies on direct links so far.
>>
>> Is there something I am missing here?
>>
>> Thanks
>
> basically you need to follow the embedded documentation link on the home
> page to get some information about this
>
> http://www.fossil-scm.org/doc/tip/www/embeddeddoc.wiki
>
> Also if you look at
>
> http://www.fossil-scm.org/doc/tip/www/branching.wiki

It would be

http://www.fossil-scm.org/index.html/doc/tip/www/embeddeddoc.wiki
http://www.fossil-scm.org/index.html/doc/tip/www/branching.wiki

>
> you will see that it contains pictures. They are GIFs in the same
> directory and are linked with a relative link such as
>
> 
>
> The fossil code that handles this is in src/doc.c if you are interested
> and can read C (or even if you can't)
>

Indeed, the first has some general info that helps with referencing
different versions of files and the later has some images.

However, the doc on embedded docs does not detail use of pictures.

The later page is included in the source tarball in www directory so I
guess that's a good example.

It looks like images magically get the correct doctype when accessed
through the doc/ urls so it's necessary to check them into the repo as
managed files and access them that way, wiki attachments won't work.

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] Internal hyperlinks, content-type and stuff

[Michal Suchanek]

Hello

I considered to use fossil for my project but the curernt release is
unusable for me.

I could not find any way for fossil to store non-text files and serve
them over http with the correct content-type, either inferred by some
magic or specified manually.

As I would like to use illustrations/diagrams/pictures in the
documentation which I hoped to store in the included wiki there is no
way to do that with fossil.

A somewhat different issue is easy linking to wiki attachments and/or
SCM objects in the docs. Since the artifacts are technically immutable
just linking to the artifact directly should suffice in most cases as
the link should not change over time but it would be nicer if there
was a way to generate links relative to the repository location so
that the links work also when the repository is moved to another
location.

Another question is how to reliably link to a particular version vs
latest version of a file which is managed by fossil.

As the wiki formatting page does not answer these question I suspect
fossil only relies on direct links so far.

Is there something I am missing here?

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] link to list archives broken

[Michal Suchanek]

Hello

the link to list archives on this page:

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

is broken.

Could somebody correct or remove it?

Thanks

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