Re: [fossil-users] Where is my deleted file in the timeline?

[Jos Groot Lipman]

Indeed, with 1.19 the problem is solved after a rebuild. Thanks.
 
Jos

  _  

From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: donderdag 6 oktober 2011 2:38
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fossil-users] Where is my deleted file in the timeline?


On Wed, Oct 5, 2011 at 4:05 PM, Jos Groot Lipman  wrote:



I had a file in my project that was no longer needed so I deleted the file
on my disk.


Only the original checkin is shown. There is no indication when or where the
file was deleted. Should that not be in de file's history?
 
The timeline for the checkin also only shows files that where changed and
added during the checkin, not the file that was deleted.


This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC


I seem to recall fixing something like that for 1.19.  Can you try using a
newer version Fossil to see if that helps.  Be sure to run "fossil rebuild"
after upgrading.

 

--

Jos Groot Lipman

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






-- 
D. Richard Hipp
d...@sqlite.org

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

Re: [fossil-users] fossil: out of memory

[Jiri Navratil]

I upgraded to 

This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC

Not sure, what I shall do in gdb. So I have this. Please let me know, what next 
I can trace. Sorry


fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error code=12)
*** error: can't allocate region
*** set a breakpoint in malloc_error_break to debug
/Users/navratil/src/fossil/fossil: out of memory

Program exited with code 01.
(gdb)

info mem
There are no memory regions defined.

(gdb) list
304   while( i 
> 
> 2011/10/4 Jiří Navrátil 
> 
> fossil sync
> Server:http://myname@192.168.1.249:8098
> Bytes  Cards  Artifacts Deltas
> Sent: 648 12  0  0
> Received: 898 11  0  1
> Total network traffic: 573 bytes sent, 718 bytes received
> fossil(25111) malloc: *** mmap(size=18446744067267100672) failed (error 
> code=12)
> *** error: can't allocate region
> *** set a breakpoint in malloc_error_break to debug
> fossil: out of memory
> I'm trying to sync repository, which is 148MB big. I'm getting out of memory 
> on Mac OS X (tested 32bit and 64bit version, 1.18 and 1.19) Fossil proces 
> crashed on 2GB on 64bit version and 1GB on 32bit version
> 
> 148Mnavratil.cz.fsl
> 
> Is something I can track, debug the reason?
> 
> Run fossil in gdb.  Figure out where malloc() is being called that causes the 
> problem.  
> 
>  
> 
> Thx,
> Jiri
> 
> 
> --
> Jiri Navratil
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> 
> 
> 
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
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: cannot connect to host www.fossil-scm.org:443

[Jiri Navratil]

I'm back to port 443. I have to accept "Unknown SSL certificate". Sync is 
working. Is Fingerprint all right? Accept always not save me before the same 
questions. I have to find, how to avoid this "WARNING: Certificate doesn't 
match the saved certificate for this host!" probably.

Thank you,
Jiri

fossil sync
Server:https://myn...@www.fossil-scm.org/fossil
Bytes  Cards  Artifacts Deltas
Sent:3132 66  0  0
waiting for server...
Unknown SSL certificate:

  organizationName  = sqlite.org
  organizationalUnitName= Domain Control Validated
  commonName= sqlite.org

Issued By:

  countryName   = US
  stateOrProvinceName   = Arizona
  localityName  = Scottsdale
  organizationName  = GoDaddy.com, Inc.
  organizationalUnitName= http://certificates.godaddy.com/repository
  commonName= Go Daddy Secure Certification Authority
  serialNumber  = 07969287

SHA1 Fingerprint:

  90 a0 0e e6 73 65 65 85 38 81 94 1f 6a 22 6c f7 80 d1 ee 0b

WARNING: Certificate doesn't match the saved certificate for this host!
Either:
 * verify the certificate is correct using the SHA1 fingerprint above
 * use the global ssl-ca-location setting to specify your CA root
   certificates list

If you are not expecting this message, answer no and contact your server
administrator.

Accept certificate [a=always/y/N]? a
Received:8371132  0  0
Total network traffic: 1917 bytes sent, 3612 bytes received

--
Jiri Navratil

6. 10. 2011 v 4:06, Richard Hipp:

> 
> 
> 2011/10/5 Jiří Navrátil 
> Thank you very much.
> 
> Based on your input, I used fossil remote-url to switch from port 443 to 80. 
> Now I can sync.
> 
> I will go back to port 443, when signed certificate will be available. I will 
> report then result then.
> 
> Please try it now and let me know how it goes.
> 
>  
> 
> Thank you,
> Jiri
> 
> --
> Jiri Navratil
> 
> 4. 10. 2011 v 20:24, Konstantin Khomoutov:
> 
> > On Tue, 4 Oct 2011 19:46:57 +0200
> > Jiří Navrátil  wrote:
> >
> >> I'm getting this output:
> >>
> >> openssl s_client -host www.fossil-scm.org -port 443
> >> CONNECTED(0004)
> >> write:errno=54
> >>
> >> not sure, which header file is applicable for me on OpenBSD
> > [...]
> >
> > I managed to find [1] which states that on your system 54 means
> > ECONNRESET, so you're facing the same issue I do.
> >
> > 1. http://fxr.watson.org/fxr/source/sys/errno.h?v=OPENBSD
> 
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
> 
> 
> 
> -- 
> D. Richard Hipp
> d...@sqlite.org
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

___
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: cannot connect to host www.fossil-scm.org:443

[Richard Hipp]

2011/10/5 Jiří Navrátil 

> Thank you very much.
>
> Based on your input, I used fossil remote-url to switch from port 443 to
> 80. Now I can sync.
>
> I will go back to port 443, when signed certificate will be available. I
> will report then result then.
>

Please try it now and let me know how it goes.



>
> Thank you,
> Jiri
>
> --
> Jiri Navratil
>
> 4. 10. 2011 v 20:24, Konstantin Khomoutov:
>
> > On Tue, 4 Oct 2011 19:46:57 +0200
> > Jiří Navrátil  wrote:
> >
> >> I'm getting this output:
> >>
> >> openssl s_client -host www.fossil-scm.org -port 443
> >> CONNECTED(0004)
> >> write:errno=54
> >>
> >> not sure, which header file is applicable for me on OpenBSD
> > [...]
> >
> > I managed to find [1] which states that on your system 54 means
> > ECONNRESET, so you're facing the same issue I do.
> >
> > 1. http://fxr.watson.org/fxr/source/sys/errno.h?v=OPENBSD
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>



-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] GUI client for Windows?

[Gilles]

Hello

I'd like to use a fat GUI client instead of the CLI or the web UI, so
checked out GUI clients for Windows.

Since I can't stand Java, I didn't try jurassic-fossil.

Apparently, the only alternative for Windows is Ingo Koch's WinFossil.

http://repository.mobile-developers.de/cgi-bin/ikoch/sharpfossil/wiki?name=WinFossil

Is there another client I should know about, free or commercial?

Thank you.

___
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

[Gé Weijers]

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.


Ge'
___
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] Where is my deleted file in the timeline?

[Richard Hipp]

On Wed, Oct 5, 2011 at 4:05 PM, Jos Groot Lipman  wrote:

> **
> I had a file in my project that was no longer needed so I deleted the file
> on my disk.
>
> Only the original checkin is shown. There is no indication when or where
> the file was deleted. Should that not be in de file's history?
>
> The timeline for the checkin also only shows files that where changed and
> added during the checkin, not the file that was deleted.
>
> This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC
>

I seem to recall fixing something like that for 1.19.  Can you try using a
newer version Fossil to see if that helps.  Be sure to run "fossil rebuild"
after upgrading.



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


-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil should know to open up perms on a file prior to update if no write access.

[Matt Welland]

My description was a bit off. The developer who initially checked in the
file without write permission is the one who cannot do the update. The
problem is not that fossil is storing or handling the perms wrong. The issue
is that a controlled file with no write permission causes fossil to barf on
an update.

It would have been fine if only the initial message was displayed:

"fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for
writing"

The remainder of the message confused the developer (and me for that
matter).

Matt
-=-
On Wed, Oct 5, 2011 at 1:25 PM, Dmitry Chestnykh wrote:

> > A developer accidentally (and naively) checked in a file with no write
> permissions.
> >
> > On changing the file and checking it in others could not do an update and
> would get something like this:
> >
> > > fossil update
> > UPDATE foo.txt
> > fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for
> writing
> > Rolling back prior filesystem changes...
> > UNDO foo.txt
> > fossil: SQLITE_ERROR: near "redoflag": syntax error
> > fossil: near "redoflag": syntax error
> > UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT
> redoflag WHERE pathname='foo.txt'
>
> Fossil doesn't track permissions apart from executable bit (and symlink bit
> in trunk), so I'm not sure how it's even possible to get a file from the
> repo without write permissions:
>
> "The optional 3rd argument defines any special access permissions
> associated with the file. The only special code currently defined is "x"
> which means that the file is executable. All files are always readable and
> writable. This can be expressed by "w" permission if desired but is
> optional."
>
> http://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki
>
> --
> Dmitry Chestnykh
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] fossil should know to open up perms on a file prior to update if no write access.

[Dmitry Chestnykh]

> A developer accidentally (and naively) checked in a file with no write 
> permissions.
> 
> On changing the file and checking it in others could not do an update and 
> would get something like this:
> 
> > fossil update
> UPDATE foo.txt
> fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for writing
> Rolling back prior filesystem changes...
> UNDO foo.txt
> fossil: SQLITE_ERROR: near "redoflag": syntax error
> fossil: near "redoflag": syntax error
> UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT 
> redoflag WHERE pathname='foo.txt'

Fossil doesn't track permissions apart from executable bit (and symlink bit in 
trunk), so I'm not sure how it's even possible to get a file from the repo 
without write permissions:

"The optional 3rd argument defines any special access permissions associated 
with the file. The only special code currently defined is "x" which means that 
the file is executable. All files are always readable and writable. This can be 
expressed by "w" permission if desired but is optional."

http://www.fossil-scm.org/index.html/doc/trunk/www/fileformat.wiki

--
Dmitry Chestnykh

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

[fossil-users] fossil should know to open up perms on a file prior to update if no write access.

[Matt Welland]

Here is the sequence of events.

A developer accidentally (and naively) checked in a file with no write
permissions.

On changing the file and checking it in others could not do an update and
would get something like this:

> fossil update
UPDATE foo.txt
fossil: unable to open file "/tmp/mrwellan/testing/test/foo.txt" for writing
Rolling back prior filesystem changes...
UNDO foo.txt
fossil: SQLITE_ERROR: near "redoflag": syntax error
fossil: near "redoflag": syntax error
UPDATE undo SET content=:c, existsflag=1, isExe=0, isLink=0 redoflag=NOT
redoflag WHERE pathname='foo.txt'
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Where is my deleted file in the timeline?

[Jos Groot Lipman]

I had a file in my project that was no longer needed so I deleted the file
on my disk.
 
Next I did:
fossil delete ViewLogAll.php
fossil commit
 
The feedback showed (among others)
# DELETED  ViewLogAll.php
 
Next I start the Fossil gui. Under 'Files' myfilename.txt is no longer shown
but when I press 'All' it show up. All perfectly normal.
 
However when I click the filename it only shows:
 
History of ViewLogAll.php

2011-08-10
  21:42
 
[2ec47ba8e9700746] part of check-in  
[2b46e45a10] Initiele versie (user:

Eigenaar branch: trunk)
 [annotate]
 
Only the original checkin is shown. There is no indication when or where the
file was deleted. Should that not be in de file's history?
 
The timeline for the checkin also only shows files that where changed and
added during the checkin, not the file that was deleted.
 
No shunning was done here :-)
 
This is fossil version 1.18 [df9da91ba8] 2011-07-13 23:03:41 UTC
--
Jos Groot Lipman
___
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)

[Erlis Vidal]

I get the two points of view and I'm not saying one is right or wrong.
Modifying the history versus keeping everything as indeed happens (the
history after all)

Yesterday I was confused because I though the shun was done in the big file,
but indeed the shun was done in the commit also... will that modify the
history? I got the feeling that shunning a commit will change the history...
not sure about it, you tell me.

If I'm working under the premisses that the history cannot be changed, is
shunning a commit (in case it change the history) a valid operation? Maybe
fossil shouldn't allow to shun a  commit, just individual files, if you
really want to shun all files in that commit, then fossil could allow that,
(shun --all) but that shouldn't touch ever the commit artifact..

Regards,
Erlis

On Wed, Oct 5, 2011 at 2:40 PM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Wed, 5 Oct 2011 11:12:31 -0700
> Mike Meyer  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.
> Correct.
>
> > 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*.
> I'm not entirely convinced.
> Look at the workflow used by the Git team: they maintain the set of
> well known branches, of which the only one, named "pu" ("proposed
> updates"), is allowed to be rebased and that's actually what happens
> with it each time the new release is made--it's cut from the master
> afresh.  I mean, while every committer has `git rebase` at their
> disposal and knows how it works this does not mean they go off and break
> the repository with rebases.  So your point is only really valid when
> the project is run by a bunch of idiots or complete newbies.
>
> > 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.
> Git handles it from the opposite direction by having "the reflog".
> But I find this point to be valid, yes, safety nets are a must when it
> comes to handling precious data.  BTW I'm a fan of `fossil undo` for
> that matter.
>
> > Bottom line: while "more features" may imply "more powerful", it
> > doesn't imply "better".
> Moot point.
> I really miss Git's "index" and `git add --patch` here.
> Is Fossil better than Git in this respect by not having those "more
> features"?  Surely it completely is in the eye of the beholder.
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] git vs fossil again (was: why you should not shun)

[Mike Meyer]

On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek wrote:

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

No, that's not how things work. Either that, or the git rebase documentation
is really badly broken. It sure looks to me like rebase moves the patches
from one point to another in the repo.


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


If rebase moves the patches, then the two operations are different. This is
basically a merge - except you're doing it outside the SCM, so you get two
copies of the patches. But whether you do it inside or outside the SCM, you
wind up with a history of the patches having been applied twice. Rebase
changes that.

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

Re: [fossil-users] git vs fossil again (was: why you should not shun)

[Konstantin Khomoutov]

On Wed, 5 Oct 2011 11:12:31 -0700
Mike Meyer  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.
Correct.

> 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*.
I'm not entirely convinced.
Look at the workflow used by the Git team: they maintain the set of
well known branches, of which the only one, named "pu" ("proposed
updates"), is allowed to be rebased and that's actually what happens
with it each time the new release is made--it's cut from the master
afresh.  I mean, while every committer has `git rebase` at their
disposal and knows how it works this does not mean they go off and break
the repository with rebases.  So your point is only really valid when
the project is run by a bunch of idiots or complete newbies.

> 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.
Git handles it from the opposite direction by having "the reflog".
But I find this point to be valid, yes, safety nets are a must when it
comes to handling precious data.  BTW I'm a fan of `fossil undo` for
that matter.

> Bottom line: while "more features" may imply "more powerful", it
> doesn't imply "better".
Moot point.
I really miss Git's "index" and `git add --patch` here.
Is Fossil better than Git in this respect by not having those "more
features"?  Surely it completely is in the eye of the beholder.
___
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] git vs fossil again (was: why you should not shun)

[Mike Meyer]

On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> 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*.

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.

Bottom line: while "more features" may imply "more powerful", it doesn't
imply "better".

 ___
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] IPv6 support and improved reverse proxying support

[Gé Weijers]

Hi Ashish,

On Wed, 5 Oct 2011, Ashish SHUKLA wrote:


I wasn't aware of both sockaddr_storage, and getnameinfo(). They seem good to
me, and I've updated diff[1] to use them.

References:
[1]  http://people.freebsd.org/~ashish/fossil-ipv6-rev-proxy.diff


A few comments (not all about your code):

You are using the ss_len member of struct sockaddr_storage. 'ss_len' is 
not required to be there by Posix AFAIK. You can just use the size 
returned by 'getsockname' or 'getpeername' (third argument).


In my own code I use getaddrinfo(..."localhost", "") to generate one 
or more sockets to allow connection to localhost only. Works quite well, 
and you don't need any special-purpose code for generating a local-only 
socket. This would require restructuring the cgi server code to handle 
multiple sockets, because on some systems (FreeBSD) you _will_ get 
multiple sockets. In general it should be possible to write both the 
client and server code without referring to a specific protocol (IPv4 or 
IPv6), except if you want to pass a specific protocol to getaddrinfo.


It would simplify things if you pass the port number to 'getnameinfo' as a 
string in stead of assigning it later in your code. This code could then 
be removed:


+if(i->ai_family == AF_INET) {
+  ((struct sockaddr_in*)i->ai_addr)->sin_port = htons(g.urlPort);
+} else if(i->ai_family == AF_INET6) {
+  ((struct sockaddr_in6*)i->ai_addr)->sin6_port = htons(g.urlPort);
+}


The existing code (before your patch) has one problem: if a connection 
disappears between the return of 'select' and the 'accept' call the accept 
can 'hang' until the next connection gets made. The 60 second timeout will 
therefor not always work. The way to get around that is set the listening 
socket to non-blocking, and turn non-blocking back off for the socket you 
get from 'accept'. If accept produces and error with errno equal to 
EWOULDBLOCK or ECONNABORTED you just ignore it.


I've attached some sample code that more or less implements this. The code 
does not fork a new process, but it does the other stuff.


Ge'#include 
#include 
#include 
#include 
#include 

#include 
#include 
#include 
#include 
#include 
#include 
#include 

int open_server_sockets(int socklist[], unsigned maxsock, const char *host, 
const char *svc)
{
 int r;
 struct addrinfo hints, *res, *res0;
 const char *fail = NULL, *code = NULL;
 unsigned numsock = 0;
 memset(&hints, 0, sizeof(hints));
 hints.ai_flags = AI_ADDRCONFIG | AI_PASSIVE;
 hints.ai_family = PF_UNSPEC;
 hints.ai_socktype = SOCK_STREAM;
 hints.ai_protocol = IPPROTO_TCP;

 r = getaddrinfo(host, svc, &hints, &res0);
 if(r != 0){
  fprintf(stderr, "can't resolve %s:%s: %s\n", (host ? host : "ANY"), 
(svc ? svc : "ANY"), gai_strerror(r));
  return -1;
 }
 for(res = res0; res != NULL && numsock < maxsock; res = res->ai_next){
  int s = socket(res->ai_family, res->ai_socktype, res->ai_protocol);
  int yes = 1, t;
  if(s < 0){
   fail = "socket"; code = strerror(errno);
   continue;
  }
  if(setsockopt(s, SOL_SOCKET, SO_REUSEADDR, &yes, sizeof(yes)) < 0){
   fail = "setsockopt"; code = strerror(errno);
   continue;
  }
  if(bind(s, res->ai_addr, res->ai_addrlen) < 0){
   fail = "bind"; code = strerror(errno);
   continue;
  }
  t = fcntl(s, F_GETFL, 0);
  if(t < 0 || fcntl(s, F_SETFL, t | O_NONBLOCK) < 0){
   fail = "fcntl"; code = strerror(errno);
   continue;
  }
  if(listen(s, 256) < 0){
   fail = "listen"; code = strerror(errno);
   continue;
  }
  socklist[numsock++] = s;
 }
 freeaddrinfo(res0);
 if(numsock == 0 && fail){
  fprintf(stderr, "%s failed: %s\n", fail, code);
  return -1;
 }else if(fail){
  fprintf(stderr, "warning: %s failed: %s\n", fail, code);
 }
 return (int)numsock;
}

int simple_server(int sock)
{
 char host[NI_MAXHOST], svc[NI_MAXSERV];
 int err, t;
 struct sockaddr_storage sa;
 socklen_t salen = sizeof(sa);
 if(getpeername(sock, (struct sockaddr *)&sa, &salen) < 0){
  fprintf(stderr, "can't get peer address: %s\n", strerror(errno));
  return -1;
 }
 if((err = getnameinfo((struct sockaddr *)&sa, salen, host, sizeof(host), 
svc, sizeof(svc), NI_NUMERICHOST | NI_NUMERICSERV)) < 0){
 fprintf(stderr, "can decode socket address: %s\n", gai_strerror(err));
 return -1;
 }else{
  printf("connection originating from %s:%s\n", host, svc);
 }
 t = fcntl(sock, F_GETFL, 0);
 if(t < 0 || fcntl(sock, F_SETFL, t & ~O_NONBLOCK) < 0){
  fprintf(stderr, "can't turn off O_NONBLOCK: %s\n", strerror(errno));
  return -1;
 }
 return 0;
}

int main ()
{
 enum { N = 20 

Re: [fossil-users] git vs fossil again (was: why you should not shun)

[Konstantin Khomoutov]

On Wed, 5 Oct 2011 18:24:30 +0200
Lluís Batlle i Rossell  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?
> 
> Exactly, these are usual arguments among git lovers.
> 
> Nevertheless, git manuals say "every commit represents a state of the
> tree". Then you may find logical to expect that every commit log
> talks about a state of the tree. BUT all this goes away, when you
> start using 'rebase'. The commit logs once written do not match
> anymore the 'state of the tree' at the time of commit log writing.
> Assertions in commit logs like "this part works" may easily not fit
> what was meant at the commit time, for example.
> 
> git even comes with 'quick automatic rebase' facilities, that allow
> not rechecking any commit log (a task hard to do, in any case).
> 
> Making a review 'easier' by manipulating history can also end up
> being some kind of manipulation to a reviewer. A reviewer may judge
> better by understanding the development.
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.
___
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] [vb.net] Which files/folders can be safely ignored?

[Gilles]

On Tue, 4 Oct 2011 15:14:56 +0200, Dmitry Chestnykh
 wrote:
>I don't know a lot about Visual Studio, but*.sln looks to me like a solution 
>file, don't ignore it.
>
>According to the git ignore template here 
>https://github.com/github/gitignore/blob/master/VB.Net.gitignore,
>*.user and *.suo are safe to ignore.

Thank you.

___
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: cannot connect to host www.fossil-scm.org:443

[Jiří Navrátil]

Thank you very much.

Based on your input, I used fossil remote-url to switch from port 443 to 80. 
Now I can sync.

I will go back to port 443, when signed certificate will be available. I will 
report then result then.

Thank you,
Jiri

--
Jiri Navratil

4. 10. 2011 v 20:24, Konstantin Khomoutov:

> On Tue, 4 Oct 2011 19:46:57 +0200
> Jiří Navrátil  wrote:
> 
>> I'm getting this output:
>> 
>> openssl s_client -host www.fossil-scm.org -port 443
>> CONNECTED(0004)
>> write:errno=54
>> 
>> not sure, which header file is applicable for me on OpenBSD
> [...]
> 
> I managed to find [1] which states that on your system 54 means
> ECONNRESET, so you're facing the same issue I do.
> 
> 1. http://fxr.watson.org/fxr/source/sys/errno.h?v=OPENBSD

___
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

[Ron Wilson]

On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp  wrote:
> Fortunately, there was still one other copy in the undo stack

I would add a fourth lesson: Always backup your work.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] git vs fossil again (was: why you should not shun)

[Lluís Batlle i Rossell]

On Wed, Oct 05, 2011 at 06:06:07PM +0200, Michal Suchanek wrote:
> 2011/10/5 Lluís Batlle i Rossell :
> > 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.

I consider commits as relevant milestones in the development, and I use branches
to keep differentg granularity of 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?

Exactly, these are usual arguments among git lovers.

Nevertheless, git manuals say "every commit represents a state of the tree".
Then you may find logical to expect that every commit log talks about a state of
the tree. BUT all this goes away, when you start using 'rebase'. The commit logs
once written do not match anymore the 'state of the tree' at the time of commit
log writing. Assertions in commit logs like "this part works" may easily not
fit what was meant at the commit time, for example.

git even comes with 'quick automatic rebase' facilities, that allow not
rechecking any commit log (a task hard to do, in any case).

Making a review 'easier' by manipulating history can also end up being some
kind of manipulation to a reviewer. A reviewer may judge better by understanding
the development.

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

git even cannot store branch histories, beyond the big resulting graph of
unnamed commits. For example, a branch name can only designate a commit (leaf),
not more than one. And branch names are not part of history.
Some git deployments even forbid or limit pushing new branches to a public
repository.

On the other hand, fossil will always respect the checkin order, and the states
related to every checkin log. As many other VCS, but not with git.

Regards,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Listing artifact IDs for shunning?

[Matt Welland]

On Wed, Oct 5, 2011 at 12:19 AM, Eric  wrote:

>
> On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
> ...
> > Every time pragmatism loses to philosophy someone, somewhere, is gonna
> get
> > screwed.
>
> But "pragmatic" decisions made by someone who doesn't understand the
> philosophy/principles/rules can also cause problems,
>

Trying to defend against ignorance by shackling the hands of the
non-ignorant will likely alienate some the non-ignorant. Irrelevant,
illegal, embarrassing or burdensome stuff will occasionally make it into a
fossil repo and being able to remove such items is a hard requirement for me
and I suspect for quite a few others. Fossil already has a reasonable
compromise in this regard.

> It is noble to have a philosophy of "don't rewrite history" but only to an
> extent. Some obvious and perhaps not so obvious examples have been
> mentioned
> in this thread.

"Those who rewrite history are condemned to repeat it" perhaps.
>

I see only the weakest of connections between this statement and reality in
this context.

> I think fossil has a nice balance here. It is possible to remove stuff but
> it takes a little effort. Never deleting stuff is just silly. An record of
> the past that stores irrelevant data is quite likely less useful than a
> record that has been cautiously cleaned up.

Define "irrelevant", including how you can be absolutely sure that it
> applies to any particular case.
>

In any given domain the non-ignorant will know with very little effort the
difference between relevant and irrelevant. Accidentally checking in a
couple hundred megs of data from the wrong project into a fossil repo is
almost guaranteed to happen someday by someone on our dev. team. That data
is easily discerned as irrelevant to anyone on the project. People make
mistakes. As the advocate and admin for fossil I need to be able to recover
gracefully from those mistakes. I don't need the process of removing the
data to be made easy but I do need it to be possible.

> I'd personally like to see a mechanism that does the following:
>
> 1. Stops the object(s) from being propagated or received.
> 2. Hides the objects(s) from view, (but can be enabled to show again)
> 3. After a period of time, I think about a year, the data is removed
> entirely.

Not altogether a bad idea but, as you might expect, I would worry about how
> to select the time interval, and I think the system should insist on
> keeping a comment about the deletion.
>

Making the time interval configurable would be fine. A comment is going to
be just noise and noise distracts but that is fine also.

I did forget "# 4. Make sure the objects are not inadvertently referenced
anywhere in fossil once hidden."

Eric
>
> --
> ms fnd in a lbry
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
>
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Listing artifact IDs for shunning?

[Steve Havelka]

On 10/5/11 2:19 AM, Eric wrote:

On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
...

Every time pragmatism loses to philosophy someone, somewhere, is gonna get
screwed.

But "pragmatic" decisions made by someone who doesn't understand the
philosophy/principles/rules can also cause problems,


Sure, but come on.  It's a version control system, and the idea I'm 
talking about is "never delete anything".  This isn't a particularly 
heavy philosophy, nor are we treading on particularly new ground.  It's 
an idea that, in daily practice, has some irritating consequences (and 
the occasional list chatter seems to indicate this, too).  And besides, 
Fossil's already made one acknowledgment that, if it's 
spam/unwanted/etc, you can delete it, it just doesn't make it easy.  I'd 
just suggest that it could be made easier for other use cases 
(accidentally-checked-in password file, etc) as well, even if it 
remained officially discouraged.




It is noble to have a philosophy of "don't rewrite history" but only to an
extent. Some obvious and perhaps not so obvious examples have been
mentioned
in this thread.

"Those who rewrite history are condemned to repeat it" perhaps.


I'm not trying to be snarky, but I'm having a bit of trouble following 
how this familiar aphorism apply here.  Are you saying that, if I 
accidentally committed a password file, and wanted to delete it from my 
and all other repos, if Fossil let me, then I might accidentally do so 
again later?  But if I had to shun it and then chase down all the other 
repos and shun it from them all, then I wouldn't?




I think fossil has a nice balance here. It is possible to remove stuff but
it takes a little effort. Never deleting stuff is just silly. An record of
the past that stores irrelevant data is quite likely less useful than a
record that has been cautiously cleaned up.

Define "irrelevant", including how you can be absolutely sure that it
applies to any particular case.


I'm also not sure why it would be necessary to present a universal 
definition of "irrelevant".  How about, instead:  Fossil's a good 
program already but it has one non-technical limitation that causes some 
occasional friction in use, which has inspired at least one inelegant 
workaround (export to git, modify, import from git).  Or I'd try, we're 
probably mostly professionals who use the software daily, and we're 
generally good at what we do but because we're also human, we still make 
mistakes from time to time, and the software could be more forgiving in 
helping us fix those?


Don't get me wrong, I use fossil on a near-daily basis and I'm generally 
quite pleased with it.  But I also don't think it's a mature program or 
has finished its development, and I'd just like to toss my two cents in 
as a mostly-satisfied user, about where I think it could be further 
improved.



___
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] Shunning for testing

[Richard Hipp]

2011/10/5 Lluís Batlle i Rossell 

> Hello,
>
> if I shun any contents from a repository, and rebuild... can I later
> 'unshun'
> them, and then expect a 'pull' to get them from whatever repository
> containing
> them?
>

I can't think of a reason why that wouldn't work.

-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Shunning for testing

[Lluís Batlle i Rossell]

Hello,

if I shun any contents from a repository, and rebuild... can I later 'unshun'
them, and then expect a 'pull' to get them from whatever repository containing
them?

Regards,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PATCH] IPv6 support and improved reverse proxying support

[Ashish SHUKLA]

Lluís Batlle i Rossell writes:
> On Mon, Oct 03, 2011 at 11:58:08AM -0700, Gé Weijers wrote:
>> 
>> 
>> On Mon, 3 Oct 2011, Lluís Batlle i Rossell wrote:
>> 
>> >Additionally, I don't know how portable it is to use always getaddrinfo
>> >(POSIX-2001?) while requiring C89.
>> 
>> C89 does not address networking, so this issue is unrelated to C89.
>> If getaddrinfo is not supported on a platform that uses the socket
>> API it may be time to move away from it :-(

> :) I agree. I was just wondering, how old (or simple) systems/compilers we
> expect fossil to build on.

>> The only extra complexity it adds is that a server has to be able to
>> listen to multiple sockets. Some OSes may give you a single socket
>> that can handle both IPv4 and IPv6 connections, and others will not.

> I know I know. But posix allows a 'setsockopt' to force it do both ipv4 and 
> ipv6
> in the same socket, isn't it? Different OSes have different 'defaults' for 
> that
> though.

IPV6_V6ONLY, and this patch explicitly disables that socket option to make
sure that AF_INET6 socket should be able to receive IPv4 connections as well.

HTH
-- 
Ashish SHUKLA

“Vengeance is mine; I will repay.” (Leo Tolstoy, "Anna Karenina",
(1875–1877))


pgpaVuEjjmBpp.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] [PATCH] IPv6 support and improved reverse proxying support

[Ashish SHUKLA]

Gé Weijers writes:


> On Mon, 3 Oct 2011, Konstantin Khomoutov wrote:

>> Is there no way to make it switchable at runtime (like via `fossil set
>> ipv6 on`) or is it doable but just complicated to implement?
>> Having a compile-time switch effectively doubles the number of binaries
>> one have to built to offer for downloading.  The same issue arises for
>> downstream distro packagers.

> It's doable and not that complicated. The patch submitted is much more
> complicated than it needs to be, esp. on the server side.

Thanks for the time to review the code. Assuming good support for IPv6 in
major Unixen, I decided not to do any runtime magic.

> All this #ifdef stuff is not necessary. Looking at the patch I saw several
> issues:

> - not using 'struct sockaddr_storage' but casting a char[256] to a struct
>   sockaddr pointer (alignment)
> - using an overly complicated method to get a representation of the IP
>   address (use 'getnameinfo' in stead)

> It is not necessary to even specify the protocol, unless you want to
> force the use of IPv4 or IPv6. The complexity is hidden in the library
> routines
> 'getnameinfo' and 'getaddrinfo'.

I wasn't aware of both sockaddr_storage, and getnameinfo(). They seem good to
me, and I've updated diff[1] to use them.

References:
[1]  http://people.freebsd.org/~ashish/fossil-ipv6-rev-proxy.diff

HTH
-- 
Ashish SHUKLA

“Well, I guess cyborgs like myself have a tendency to be paranoid
about our origins.” (Motoko Kusanagi in movie "Ghost in the Shell")


pgpXPbDG02YHv.pgp
Description: PGP signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Listing artifact IDs for shunning?

[Alaric Snell-Pym]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 10/05/2011 08:19 AM, Eric wrote:

> Not altogether a bad idea but, as you might expect, I would worry about how
> to select the time interval, and I think the system should insist on
> keeping a comment about the deletion.

Perhaps shuns should be proper objects, like commits, that end up as
sentinel objects marking the shunned objects; so if you shun a version
of a file, when you try and check that version of the repository out,
it'll encounter the shun while traversing the directory tree and will
print out:

"login.c - SHUNNED "

...and login.c will be missing.

This will involve a lot of extra cases to check; whenever we fetch an
object from the repo and process it in some way, we'll need fallback
cases for if we get a shun. But I hope we already have those checks in
place for the error that will arise when trying to get an object that is
missing because it was shunned!

>
> Eric
>

ABS

- --
Alaric Snell-Pym
http://www.snell-pym.org.uk/alaric/
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAk6MIUQACgkQRgz/WHNxCGok3ACfWXKfdtE+950mWpA/IuDStsYR
IMYAn1GqjNGQ22sDEDP4Bt8fxHIgPGus
=/T1N
-END PGP SIGNATURE-
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Specifying files on the command line

[Lluís Batlle i Rossell]

On Tue, Oct 04, 2011 at 07:12:49PM -0400, Richard Hipp wrote:
> There is a fossil-dev mailing list now.  I added it to this thread - to see
> if it actually works.  Assuming the new mailing list does work, we should
> try to move these kinds of discussions there, to minimize the noise for
> people how just want to be Fossil users and don't care so much about the
> implementation details.

I subscribed to the list using this link. I just changed "-users" to "-dev"
based on the link in the front page of fossil-scm.org. I don't know if I should
have found the link anywhere else.

http://lists.fossil-scm.org:8080/cgi-bin/mailman/subscribe/fossil-dev

I see the archives are set to 'private' for that mailing list. Do you prefer to
keep them private?

I agree some users may even get frightened about some development letters. :)

Thank you very much,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] Listing artifact IDs for shunning?

[Eric]

On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
...
> Every time pragmatism loses to philosophy someone, somewhere, is gonna get
> screwed.

But "pragmatic" decisions made by someone who doesn't understand the
philosophy/principles/rules can also cause problems,

>
> It is noble to have a philosophy of "don't rewrite history" but only to an
> extent. Some obvious and perhaps not so obvious examples have been
> mentioned
> in this thread.

"Those who rewrite history are condemned to repeat it" perhaps.

> I think fossil has a nice balance here. It is possible to remove stuff but
> it takes a little effort. Never deleting stuff is just silly. An record of
> the past that stores irrelevant data is quite likely less useful than a
> record that has been cautiously cleaned up.

Define "irrelevant", including how you can be absolutely sure that it
applies to any particular case.

>
> I'd personally like to see a mechanism that does the following:
>
> 1. Stops the object(s) from being propagated or received.
> 2. Hides the objects(s) from view, (but can be enabled to show again)
> 3. After a period of time, I think about a year, the data is removed
> entirely.

Not altogether a bad idea but, as you might expect, I would worry about how
to select the time interval, and I think the system should insist on
keeping a comment about the deletion.

Eric

-- 
ms fnd in a lbry

___
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

[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.

And as determined by the creator, Linus, git is more like a tool meant for
sharing code preserving contributions authorship, other than storing development
history. I think Linus did not want for the kernel a storage for development
history; he only wanted to manage the contributions.

Regards,
Lluís.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users