Re: [fossil-users] xkcd on git

[Konstantin Khomoutov]

On Sat, 31 Oct 2015 09:53:52 +0100
Stephan Beal  wrote:

> > Unless you delete .git your checkout is always in well defined
> > state.
> No, it's not. i once literally had one of the libgit maintainers at
> my desk for a full hour trying to get my repo (of a project we were
> both working on for our employers) back in a pushable state after it
> got jumbled up by me copy/pasting commands suggested by StackOverflow
> (about the worst place to get git advice). If one of the developers
> takes that long to straighten it out, then something is (IMO)
> fundamentally wrong.

That's still barking at the wrong tree.

You're unlikely to screw up a Fossil repo *that* much by
mindlessly copying-and-pasting something from SO but that's because
Fossil simply does not expose commands which allow you do perform
intricate surgeries on your repo.  To perform such fine operations, you
have to be trained at them or just abstrain from doing them.  Or at
least try them in a sandbox first.  It's like you being able to
actually disassemble your car and them have a skilled technician
assemble it back again because you have no idea how to do that.

Sure, not everyone wants to be able to perform low-level operation on
their repos, and not everyone wants to have the necessary skills.
That's absolutely OK, but claiming that that not having tools to do that
is somehow superior to another approach appears to be perfectly the same
as fanboyism of those praising the products originating from a
well-known company headquartered at Cupertino. :-)

All-in-all, I'm afraid the thread got quickly derailed from the
original problem: present DVCSs are known to suck at delivering
simple and understandable concepts to "mere mortals".
___
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

[Andy Bradford]

Thus said Scott Doctor on Fri, 30 Oct 2015 13:37:47 -0700:

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

In your  opinion, how can a  DVCS tool get the  job done in the  way you
want to do it?

Thanks,

Andy
-- 
TAI64 timestamp: 4000563779ca


___
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] SHA-1 in user.pw field

[Andy Bradford]

Thus said Warren Young on Fri, 30 Oct 2015 15:02:40 -0600:

> Are there Fossil  passwords worth that much? I think  so, and the cost
> is continually falling.

Fossil does have  the option of using  SSH and it can be  secured with a
variety  of  mechanisms that  are  more  secure than  Fossil's  built-in
password mechanism.

Andyk
-- 
TAI64 timestamp: 400056377a5b


___
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: Document --quiet option in rebuild

[Christopher M. Fuhrman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Howdy,

Discovered that the rebuild command supported an undocumented option,
- --quiet.  Since 'fossil help' was, er, quiet about the quiet option, I've
created a patch that mentions it when doing a 'fossil help rebuild'.

Example output:

Usage: ./fossil rebuild ?REPOSITORY? ?OPTIONS?

Reconstruct the named repository database from the core
records.  Run this command after updating the fossil
executable in a way that changes the database schema.

Options:
  --analyze Run ANALYZE on the database after rebuilding
  --cluster Compute clusters for unclustered artifacts
  --compressStrive to make the database as small as possible
  --compress-only   Skip the rebuilding step. Do --compress only
  --deanalyze   Remove ANALYZE tables from the database
  --force   Force the rebuild to complete even if errors are seen
  --ifneededOnly do the rebuild if it would change the schema version
  --index   Always add in the full-text search index
  --noverifySkip the verification of changes to the BLOB table
  --noindex Always omit the full-text search index
  --pagesize N  Set the database pagesize to N. (512..65536 and power of 2)
  --quiet   Only show output if there are errors
  --randomize   Scan artifacts in a random order
  --stats   Show artifact statistics after rebuilding
  --vacuum  Run VACUUM on the database after rebuilding
  --wal Set Write-Ahead-Log journalling mode on the database

See also: deconstruct, reconstruct

I am attaching the following:

 1. A bundle file containing the patch (thanks for adding that feature
BTW!)
 2. An 'old school' diff/patch with the change in it.

Please let me know if you have any questions or concerns.

Cheers!

- -- 
Christopher M. Fuhrman
cfuhr...@pobox.com

-BEGIN PGP SIGNATURE-
Version: GnuPG/MacGPG2 v2.0
Comment: GPGTools - http://gpgtools.org

iQEcBAEBCAAGBQJWN6/eAAoJEJMBHfiIBijR0pwH/0tQumInHYvu9S1Vvb5H/4tc
AqrHdUn+nsGUd1no6gFfW3DS98bkfMxtNMhdtCV5TrGeVcXU9o4c8Op4UxQHOVE4
3qEqes7q1yTTLZH9w0puFnXx9kN3KJ8yPjs1+ck2dCWv6Jf7Yt86xFtDni1H2rb3
P3EzXBLVdNVQxvhmqsnNARR+SXa0p1shPUoxlouL+/zQOjkZyymszkdZJvYLlYC3
fohjQelmH8KB/FkJarj9H9dDf0wIeqLZjtfcwI0JYd+cDkcBXI1nznC/eHpX3gcc
XNzB1rsbmam/UUJHJIeyquB+D4lDOqbcMjalpphJJmmLWjAYgV3KrKsG8Lzj2x4=
=I5RP
-END PGP SIGNATURE-Index: src/rebuild.c
==
--- src/rebuild.c
+++ src/rebuild.c
@@ -533,10 +533,11 @@
 **   --ifneededOnly do the rebuild if it would change the schema 
version
 **   --index   Always add in the full-text search index
 **   --noverifySkip the verification of changes to the BLOB table
 **   --noindex Always omit the full-text search index
 **   --pagesize N  Set the database pagesize to N. (512..65536 and power 
of 2)
+**   --quiet   Only show output if there are errors
 **   --randomize   Scan artifacts in a random order
 **   --stats   Show artifact statistics after rebuilding
 **   --vacuum  Run VACUUM on the database after rebuilding
 **   --wal Set Write-Ahead-Log journalling mode on the database
 **



cmf-doc-quiet-rebuild.bundle
Description: Binary data
___
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: Document --quiet option in rebuild

[Richard Hipp]

On 11/2/15, Christopher M. Fuhrman  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Howdy,
>
> Discovered that the rebuild command supported an undocumented option,
> - --quiet.  Since 'fossil help' was, er, quiet about the quiet option, I've
> created a patch that mentions it when doing a 'fossil help rebuild'.
>

Thanks.  This is the first check-in after the 1.34 release.

-- 
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] symlinks

[Richard Hipp]

Fossil version 1.34 has been tagged and binaries are now available on
the website (except for OpenBSD, which I cannot build at the moment
because devio.us is down, but probably anybody who uses OpenBSD can
run "./configure; make" against the tarball.)

So now would be a good time to hack away at a better implementation of symlinks.
-- 
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] symlinks (was Re: xkcd on git)

[bch]

On Nov 2, 2015 9:32 AM, "Eric Rubin-Smith"  wrote:
>
>
 My problem is not the decision itself, but that, in terms of how
fossil should behave, it's a philosophical question. Those have no
right/wrong answer, and i dislike seeing software pretend to know the
answer to such questions.
>>>
>>>
>>> Isn't that essentially confirming my point? Fossil merely stores the
pointer. It need not waste time analysing the link to make a judgement call
in any way. Just store it and move on.
>>
>>
>> But if it only stores a pointer, and requires the user to reconstruct
the link, it's not terribly useful/friendly. The user would potentially
have to replace fossil's placeholder pseudosymlink file with a link of his
own (which he could point somewhere else than fossil thinks it "should"
be). He might has well simply have a "post-checkout" script which sets up
his symlinks for him. To me, that's the "proper"/"safest" way to handle
symlinks in a repo (but i'm willing to accept being in the minority on that
point).
>
>
> Fossil's poor handling of symlinks is a severe knock against it, both in
my opinion and in my experience with proselytizing it to people who are not
already on the fossil kool-aid.

Philosophically, I think of links as build artifacts, which are rarely
stored in an scm. I do avoid them as much as possible, but I've
occasionally wondered: does anybody manage the links as the build artifacts
of a script, and keep the script itself under version control?

So, if you need: foo -> bar, do this:

#!/bin/sh
ln -sf bar foo

... and store that script under VC?

> Every time a user opens our repo on unix, the symlinks are initially
populated as regular files whose contents are the link target.  This is
causes me significant embarrassment for recommending fossil when others on
my project have to deal with it.  (I tried pushing through a code patch a
year or so ago to fix this, but I detected some bug or another with it and
I don't think the devs ever accepted the patch (not sure).)
>
> Note that this a Fossil-specific quirk.  Not all cross-platform programs
are equally awkward in their symlink handling -- in fact, most are better.
>
> Stephan: I think that you are overcomplicating the matter, in the sense
that the complications you note can (and should) be passed on to the user
-- in the same way that the program tar(1) might pass on such complications
to the user when trying to move a tarball from one OS to another.  In other
words, I believe that you perceive a dichotomy that is false (between (a)
not implementing symlinks at all and (b) implementing them while having
fossil perfectly and automatically solve all complications that may arise).
>
> A user who only ever uses fossil on unix should get unix symlink
semantics on unix, without quirks or surprises.  Surely you and DRH would
agree with that?
>
> The cases you are worried about:
>
> * absolute paths -- fossil can preserve the absolute path, it's the
user's fault if that's the wrong thing to do.
> * broken links -- fossil preserves the original link, it's the user's
fault if the link is incorrectly broken.
> * cross-platform semantics -- implement the proper semantics where you
can, and don't where you can't.  A user who only ever uses fossil on unix
should get unix symlink semantics on unix.  If the fossil devs are able to
implement proper symlink handling on next year's Windows, then awesome.  If
not, then degrade to whatever and document it for the user (emitting
warning messages as appropriate or so on).
>
> Stated yet another way: we don't expect the SCM to solve all problems
that users create.  An example is naming branches incorrectly.  If the user
names a branch "" when the project has a rule that branch names should
be descriptive, we don't expect Fossil to flag it and deal with it -- we
expect the user's coworkers to yell at them til they fix it.  So it should
be with symlinks -- each project has its own rules, Fossil doesn't know
about those rules, Fossil just faithfully syncs the target around, and if a
link gets broken in violation of project rules then a user gets yelled at
by another user.  (Note that the project-local rules might be "never use
symlinks because our Windows doesn't handle them how we would like" or "we
think symlinks are always perverse".  Fossil should not IMO be constrained
by such subsets of the user base.)
>
> For context, my particular use case: we need the openssl source tree in
our project, and that tree contains internal symlinks.  Again, people have
to jump through silly hoops to get new repos set up properly, because
fossil breaks those symlinks by populating new repos with flat text files
(and this goes undiscovered til the openssl build fails in mysterious
ways).  So their first experience with Fossil winds up being a pretty big
"WTF".
>
> My $.02,
> Eric
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> 

Re: [fossil-users] impersonating users

[jungle Boogie]

On 2 November 2015 at 22:02, Andy Bradford  wrote:
> 1) Browse to your server  (e.g. http://localhost:8080/ in your example),
> login and click on a checkin. You will see something like:
>
> Received From: tester @ 127.0.0.1 on 2015-11-03 05:56:22


Follow up question that I hope you don't mind

http://www.fossil-scm.org/index.html/info/653b6b92404c53f3
Do I not see the received from because I am not logged into the repo?

-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
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] impersonating users

[Andy Bradford]

Thus said jungle Boogie on Mon, 02 Nov 2015 22:17:50 -0800:

> http://www.fossil-scm.org/index.html/info/653b6b92404c53f3
> Do I not see the received from because I am not logged into the repo?

Correct.

Also, I  might add, that even  if you do  have a login, only  having the
right privileges will enable access  to that information. For example, a
``Developer'' does not  have access to that. Only a  user with the Admin
privilege can view it.

Andy
-- 
TAI64 timestamp: 400056385535


___
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] symlinks (was Re: xkcd on git)

[Stephan Beal]

On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith  wrote:

> the user when trying to move a tarball from one OS to another.  In other
> words, I believe that you perceive a dichotomy that is false (between (a)
> not implementing symlinks at all and (b) implementing them while having
> fossil perfectly and automatically solve all complications that may arise).
>

That sounds like a fair summary of my feelings on SCM support for symlinks,
but i'd argue that if a system (SCM) cannot do (b) for the vast majority of
use cases, then it probably shouldn't be implemented at all. Why not?
Because it's the _displeased_ users who complain the loudest when something
doesn't work how they want/expect it do, and that percentage of users is
relatively high in the case of symlinks.

A user who only ever uses fossil on unix should get unix symlink semantics
> on unix, without quirks or surprises.  Surely you and DRH would agree with
> that?
>

i can't speak for Richard, but if i had my way, fossil wouldn't support
symlinks at all. They are inherently platform-dependent and, IMHO, belong
in the build process, not the SCM. They are a big can of worms, as we can
see by large amount of emails on the topic. To be clear: i use symlinks all
over the place on my systems, i just refuse to use them in an SCM. Call me
old fashioned.


> 
> * absolute paths -- fossil can preserve the absolute path, it's the user's
> fault if that's the wrong thing to do.
>

Absolute paths in an SCM are "just plain wrong" (IMO). Even the innocuous
link to /etc might be wrong in certain build environments (and won't work
on Windows). Why should fossil assist in doing the wrong thing?

Stated yet another way: we don't expect the SCM to solve all problems that
> users create.
>

But if it sets out to solve them, then it should solve them, not provide a
half-solution to philosophically unsolvable problems. (IMO.)


> For context, my particular use case: we need the openssl source tree in
> our project, and that tree contains internal symlinks.  Again, people have
> to jump through silly hoops to get new repos set up properly, because
> fossil breaks those symlinks by populating new repos with flat text files
> (and this goes undiscovered til the openssl build fails in mysterious
> ways).
>

To the best of my knowledge, if symlinks are enabled in the fossil config,
it will DTRT with them (to the best of its ability). i haven't tried it,
but that's my understanding of the feature. IIRC symlinks are on by default
on Unix systems and off everywhere else (that info might be outdated,
though).


-- 
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
those who insist on a perfect world, freedom will have to do." -- Bigby Wolf
___
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 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

[Scott Robison]

On Mon, Nov 2, 2015 at 12:14 PM, Michal Suchanek  wrote:

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

You should read what I wrote more completely:

1. I cloned a repository.
2. I made no changes to the repository.
3. I pulled changes into my local repository.
4. I was "ahead" of the current head of the repository and I was being told
I had unstaged changes to deal with.

Someone else rewrote history. Their rewriting of history borked my local
copy of a repository that I never modified!

Yes, if I have conflicting changes, I have conflicting changes. I made no
changes, and yet git was out of sync.

In this case, rewriting history was not my choice. It was the choice of
someone else and it had a negative impact on me. I was able to fix it be
deleting my local repo and recloning, so it wasn't the end of the world,
but I have a hard time imagining a scenario where fossil would have allowed
something like that to happen.

-- 
Scott Robison
___
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

[Richard Hipp]

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.

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

[paul]

On 02/11/15 19: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.
I've worked with software engineers that have got very confused with 
Git, but the staging area isn't what they got confused about. Where they 
got into tangles was because of the distributed nature of the 
repositories. I'd say git staging is a useful feature.

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.
True, if you're talking about trunk say, and you have a policy where you 
try to ensure trunk is always correct. But if you are working on a 
feature branch, and that feature is part way through development, 
incomplete in places, knowingly broken in other places, then why would 
you have a rule of not checking in untested changes here?


Regards,

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

[Richard Hipp]

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.

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.
-- 
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] impersonating users

[Andy Bradford]

Thus said Eduard on Tue, 03 Nov 2015 00:20:08 -0500:

> I understand  why this is (I'm  not complaining); I just  want to know
> whether  there's  some  command/page  for  listing  recently  received
> control artifacts whose user does not  match the user pushing them, so
> they can be further inspected.

The  owner of  the  Fossil repository  (as well  as  user accounts  with
sufficient  privileges) can  inspect  how the  artifacts were  received.
There are a couple ways:

1) Browse to your server  (e.g. http://localhost:8080/ in your example),
login and click on a checkin. You will see something like:

Received From: tester @ 127.0.0.1 on 2015-11-03 05:56:22

The ``tester''  in that Received corresponds  to an actual user  in your
Fossil server's user database, not  the user information recorded in the
manifest of the checkin.

2) Under Admin->Artifact Receipts Log (
http://localhost:8080/rcvfromlist ) there is a list

Andy
-- 
TAI64 timestamp: 400056384e02


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

[fossil-users] symlinks (was Re: xkcd on git)

[Eric Rubin-Smith]

> My problem is not the decision itself, but that, in terms of how fossil
>>> should behave, it's a philosophical question. Those have no right/wrong
>>> answer, and i dislike seeing software pretend to know the answer to such
>>> questions.
>>>
>>
>> Isn't that essentially confirming my point? Fossil merely stores the
>> pointer. It need not waste time analysing the link to make a judgement call
>> in any way. Just store it and move on.
>>
>
> But if it only stores a pointer, and requires the user to reconstruct the
> link, it's not terribly useful/friendly. The user would potentially have to
> replace fossil's placeholder pseudosymlink file with a link of his own
> (which he could point somewhere else than fossil thinks it "should" be). He
> might has well simply have a "post-checkout" script which sets up his
> symlinks for him. To me, that's the "proper"/"safest" way to handle
> symlinks in a repo (but i'm willing to accept being in the minority on that
> point).
>

Fossil's poor handling of symlinks is a severe knock against it, both in my
opinion and in my experience with proselytizing it to people who are not
already on the fossil kool-aid.

Every time a user opens our repo on unix, the symlinks are initially
populated as regular files whose contents are the link target.  This is
causes me significant embarrassment for recommending fossil when others on
my project have to deal with it.  (I tried pushing through a code patch a
year or so ago to fix this, but I detected some bug or another with it and
I don't think the devs ever accepted the patch (not sure).)

Note that this a Fossil-specific quirk.  Not all cross-platform programs
are equally awkward in their symlink handling -- in fact, most are better.

Stephan: I think that you are overcomplicating the matter, in the sense
that the complications you note can (and should) be passed on to the user
-- in the same way that the program tar(1) might pass on such complications
to the user when trying to move a tarball from one OS to another.  In other
words, I believe that you perceive a dichotomy that is false (between (a)
not implementing symlinks at all and (b) implementing them while having
fossil perfectly and automatically solve all complications that may arise).

A user who only ever uses fossil on unix should get unix symlink semantics
on unix, without quirks or surprises.  Surely you and DRH would agree with
that?

The cases you are worried about:

* absolute paths -- fossil can preserve the absolute path, it's the user's
fault if that's the wrong thing to do.
* broken links -- fossil preserves the original link, it's the user's fault
if the link is incorrectly broken.
* cross-platform semantics -- implement the proper semantics where you can,
and don't where you can't.  A user who only ever uses fossil on unix should
get unix symlink semantics on unix.  If the fossil devs are able to
implement proper symlink handling on next year's Windows, then awesome.  If
not, then degrade to whatever and document it for the user (emitting
warning messages as appropriate or so on).

Stated yet another way: we don't expect the SCM to solve all problems that
users create.  An example is naming branches incorrectly.  If the user
names a branch "" when the project has a rule that branch names should
be descriptive, we don't expect Fossil to flag it and deal with it -- we
expect the user's coworkers to yell at them til they fix it.  So it should
be with symlinks -- each project has its own rules, Fossil doesn't know
about those rules, Fossil just faithfully syncs the target around, and if a
link gets broken in violation of project rules then a user gets yelled at
by another user.  (Note that the project-local rules might be "never use
symlinks because our Windows doesn't handle them how we would like" or "we
think symlinks are always perverse".  Fossil should not IMO be constrained
by such subsets of the user base.)

For context, my particular use case: we need the openssl source tree in our
project, and that tree contains internal symlinks.  Again, people have to
jump through silly hoops to get new repos set up properly, because fossil
breaks those symlinks by populating new repos with flat text files (and
this goes undiscovered til the openssl build fails in mysterious ways).  So
their first experience with Fossil winds up being a pretty big "WTF".

My $.02,
Eric
___
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

[Scott Robison]

On Mon, Nov 2, 2015 at 7:00 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:

> On Sat, 31 Oct 2015 09:53:52 +0100
> Stephan Beal  wrote:
>
> > > Unless you delete .git your checkout is always in well defined
> > > state.
> > No, it's not. i once literally had one of the libgit maintainers at
> > my desk for a full hour trying to get my repo (of a project we were
> > both working on for our employers) back in a pushable state after it
> > got jumbled up by me copy/pasting commands suggested by StackOverflow
> > (about the worst place to get git advice). If one of the developers
> > takes that long to straighten it out, then something is (IMO)
> > fundamentally wrong.
>
> That's still barking at the wrong tree.
>
> You're unlikely to screw up a Fossil repo *that* much by
> mindlessly copying-and-pasting something from SO but that's because
> Fossil simply does not expose commands which allow you do perform
> intricate surgeries on your repo.  To perform such fine operations, you
> have to be trained at them or just abstrain from doing them.  Or at
> least try them in a sandbox first.  It's like you being able to
> actually disassemble your car and them have a skilled technician
> assemble it back again because you have no idea how to do that.
>
> Sure, not everyone wants to be able to perform low-level operation on
> their repos, and not everyone wants to have the necessary skills.
> That's absolutely OK, but claiming that that not having tools to do that
> is somehow superior to another approach appears to be perfectly the same
> as fanboyism of those praising the products originating from a
> well-known company headquartered at Cupertino. :-)
>

I don't think such a claim is strictly a case of fanboyism. I propose that
the intended fossil model and design does not require such low level tools,
whereas git is a more fragile system and thus its low level tools were born
of necessity.

Getting back to the comic itself: At my job we have a particular repo that
includes a bunch of tools / scripts / whatever used in the CM process. It
is only written / updated by the CM team, and I only have to clone it /
pull it to use it. I never edit it in any way.

So imagine my surprise a couple weeks ago when I tried to pull some updates
and was warned that I was some number of edits ahead of the remote head
(ie, I had uncommitted changes). In reviewing my supposed "changes" (which
I did not make) I could only come to the conclusion that someone (contrary
to policy) had made some sort of remote repo modification (rewrote history)
that left me in a bad state. I wound up deleting and re-cloning just as the
comic suggests.

I don't think that state would be attainable in fossil without some sort of
extreme case. Certainly the normal set of commands provided and used in
fossil repo maintenance / usage would not make that possible.

Or maybe it would. I'd love to hear some example of how that might happen
in fossil.

It's one thing to be actively using a repository and using the full set of
repo management commands (open, update, commit, branch, etc) and getting
into some state where merging is difficult. It is another to have made no
changes to a clone of a repo and to be told you have uncommitted changes.

-- 
Scott Robison
___
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

[Scott Robison]

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.

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

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

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

As for my use of git (because my employer has been migrating to git from
svn for a while now, though we're not 100% migrated yet), I find it
maddening. I have used fossil on some projects and wind up committing the
"final product" to git when necessary (since git fans seem to find
intermediate history objectionable or of little value, it doesn't seem too
bad that git doesn't get the same level of history as I have in my repo).

-- 
Scott Robison
___
fossil-users mailing list

[fossil-users] Referencing files through a convenience symlink

[Warren Young]

I have a Fossil repo with a few convenience symlinks in it.  They exist just to 
reduce the apparent directory depth in a few places.  

I’ve enabled allow-symlinks, since without that, Fossil misbehaves.  But with 
the setting enabled, Fossil refuses to dereference a symlink, which causes 
usability problems:

  mkdir tmp
  cd tmp
  f new ../x.fossil
  f open ../x.fossil 
  mkdir -p foo/bar
  echo 'stuff' >> foo/bar/qux
  f add foo/bar/qux
  f ci -m 'added qux'
  f set allow-symlinks 1
  ln -s foo/bar .
  f add bar
  f ci -m 'added convenience symlink'
  echo 'stuff' >> bar/qux
  f ci bar -m 'added stuff'   # claims nothing has changed!
  f finfo bar/qux # claims no history for file!

If you repeat the same test except without the “f set” command, it appears to 
work as expected, but on reopening the repository, you have a real bar 
directory containing a second qux file.  That second file has the same contents 
as foo/bar/qux initially, but it’s an independent file, so changes to one don’t 
affect the other.

I can see why Fossil might not want to blindly dereference a symlink, in case 
it points outside the Fossil-managed checkout tree, but why refuse in this case?
___
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

[Warren Young]

On Nov 1, 2015, at 6:09 PM, Ron W  wrote:
> 
> On MS Windows, that is how it has to be done. Symlinks require the user be an 
> admin

Yes, but also, you must be running cmd.exe *as* Admin if you have UAC enabled, 
since the normal cmd.exe window can’t auto-elevate itself.

> and use a special command that is separately installed.

That sounds like old information.  MKLINK is a cmd.exe builtin.

Simple test case:

  c:\> set PATH=
  c:\> mklink /?
  Creates a symbolic link.

  MKLINK [[/D] | [/H] | [/J]] Link Target

/D  Creates a directory symbolic link.  Default is a file
symbolic link.
/H  Creates a hard link instead of a symbolic link.
/J  Creates a Directory Junction.
LinkSpecifies the new symbolic link name.
Target  Specifies the path (relative or absolute) that the new link
refers to.

  c:\> mklink ASeriesOfUnfortunateEvents Windows
  You do not have sufficient privilege to perform this operation.

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

[Richard Hipp]

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.)
-- 
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] symlinks (was Re: xkcd on git)

[bch]

On 11/2/15, Ron W  wrote:
> On Mon, Nov 2, 2015 at 1:16 PM, bch  wrote:
>>
>> Philosophically, I think of links as build artifacts, which are rarely
>> stored in an scm. I do avoid them as much as possible, but I've
>> occasionally wondered: does anybody manage the links as the build
>> artifacts
>> of a script, and keep the script itself under version control?
>>
> We used to, but now use the vpath directive in GNU make, so longer need
> symlinks.

After I posted this, I thought a Makefile (still to manage actual
symlinks) would be an improvement over a shell script; you're punting
on symlinks completely (using VPATH). How has VPATH (or the previous
shell script) treated you as a symlink manager/replacement ?

-bch


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

[Warren Young]

On Nov 2, 2015, at 4:31 PM, Jan Danielsson  wrote:
> 
>   I don't know which is worse; not supporting symlinks at all on
> Windows, or telling people that they need to have administrator
> privileges on their system in order to check the code out

I agree, which is why the policy decision needs to be made at the repo level, 
not at the fossil-scm.org level.

If you don’t want the downsides your post mentions, don’t check symlinks into a 
repo that needs to be opened on Windows.

If you have a repo that needs to open on Windows and the administrator of that 
repo decides that it legitimately needs symlinks, Fossil should support that 
use case as best as it can.

Obviously there is a limit to the amount of heroism we should expect from 
Fossil and its developers.
___
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

[Scott Robison]

On Mon, Nov 2, 2015 at 5:01 PM, Ron W  wrote:

> On Mon, Nov 2, 2015 at 6:38 PM, Scott Robison 
> wrote:
>>
>> From https://en.wikipedia.org/wiki/NTFS_symbolic_link#Restrictions: The
>> default security settings in Windows Vista/Windows 7
>>  disallow non-elevated
>> administrators and all non-administrators from creating symbolic links. *This
>> behavior can be changed running "secpol.msc" the Local Security Policy
>> management console (under: Security Settings\Local Policies\User Rights
>> Assignment\Create symbolic links). It can be worked around by starting 
>> **cmd.exe
>>  with Run as administrator option or
>> the runas  command.*
>>
>
> Where I work, we would to ask IT to modify the policy for us. Given how
> many years it took of them having to install the specialized tools we in
> Product Engineering need before IT agreed to grant us local admin privs, I
> would expect similar.
>
> I suppose runas could be used in BAT files (much like sudo can be).
>
> But, as I said in another post, we have been able to get away from
> symlinks by using the vpath feature of GNU make.
>

In my work as well it is often a chore to get IT to change corporate
enforced policies, so this might not be an option in some environments. As
for me and my own development, however, I can easily get fossil to create
symlinks with my winsymlink branch as long as I can get an elevated prompt
or can get a non-admin user with symlink rights.

I guess what I'm saying is that most of the effort has already been
expended on Windows symlink support. At this point I think it's just
permissions.

-- 
Scott Robison
___
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

[Jan Danielsson]

On 03/11/15 00:38, Scott Robison wrote:
>>> On 11/2/15, Jan Danielsson  wrote:

   Supporting symlinks on Windows would currently be a little mess.
>>>
>>> What if we just say that symlinks don't work on Windows and that if
>>> you include them in your repo, you won't be able to checkout (sanely)
>>> on Windows?
>>
>> I think Fossil should give a best-effort try via UAC, but yeah, if that
>> doesn’t work, no tears should be shed about it.
>>
> 
> I know I've posted this before, but just to reiterate:
> 
> If you are an unprivileged user, you can create symlinks if you've been
> granted the symlink priv. It is not hard to do at all.

   Sure, but that means instructing people to change a system policy to
be able to check out code in repositories which use symlinks.

   Unless we pop up a question "Do you want to reconfigure the system to
allow symlinks?" if needed, that would be more acceptable to me, but how
do we handle domain environments where GPO's are pushed out by the
domain controller, and the user can't change that setting?

> The problem comes with UAC for unelevated administrative users only,
> because Microsoft in their infinite wisdom saw fit to strip symlink privs
> from unelevated admin users by default.

   Agreed.

> One: Most windows users wouldn't be using symlinks and wouldn't care.

   Agreed, again.

> Two: It's not hard to have two command prompts open, one running as a non
> admin user with symlink privs. One could run fossil from the non admin
> user. Or one could easily run fossil as the non admin user that has symlink
> privs.

   This may surprise some of you, but I can point to a large IT
consultant firm with thousands of developers world-wide who do _not_
have administrator privileges on their own systems.  They simply can't
open elevated command line prompts, unless they are driver developers
who have been given special privileges due to specific project requirement.

   I agree it's a theoretical point in this specific discussion, but
just reminding that being able to open up an elevated command prompt can
actually be a luxury in some environments, so it's not a "catch all"
solution in Windows.

> Maybe it's not worth doing, and maybe I shouldn't have bothered adding real
> symlink support in the winsymlink branch. However, it is possible, and it's
> not as onerous as many people are making it out to be.

   My skepticism boils down to the fact that we can't make a general
solution which will work smoothly everywhere[*].  Call it OCD if you
will, but I think "We support symlinks on Windows, but not without
policy changes to the system and not in these types of special
environments." looks a little iffy, considering there are no such
caveats on other platforms.

   That said, like I said earlier, I don't object to anyone willing to
give it a shot, and seeing as you already have done it, then there's no
sense in me making the argument that it would be better to wait until
symlinks on Windows are more polished.

   I am curious to know though how you get the reparse point, and if
you've encountered those hangs.  I didn't know about the winsymlink
branch, so I'll take a look.


   [*] In practical terms, as you say, more or less zero users (today)
will encounter these problems.  As stated; to me it's more the asymmetry
which bothers me.

-- 
Kind Regards,
Jan
___
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] Can't build Fossil 1.34 with Tcl 8.5

[Jan Nijtmans]

2015-11-02 23:43 GMT+01:00 Piotr Orzechowski :
> Hi,
>
> I can't build Fossil 1.34 with Tcl 8.5 (8.5.0-2.1) on fully up-to-date
> Debian Wheezy 64-bit.
>
> I configure Fossil with:
>
> ./configure --prefix=/opt --with-openssl --with-tcl=/usr/lib/tcl8.5
> --with-th1-hooks --json --with-zlib

Just add the options --with-tcl-stubs and --with-tcl-private-stubs,
then it will work fine. (Don't ask me why this isn't the default
when using --with-tcl, I think it should be)

Regards,
 Jan Nijtmans
___
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

[Richard Hipp]

On 11/2/15, Jan Danielsson  wrote:
>
>Supporting symlinks on Windows would currently be a little mess.

What if we just say that symlinks don't work on Windows and that if
you include them in your repo, you won't be able to checkout (sanely)
on Windows?

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

[Warren Young]

On Nov 2, 2015, at 3:56 PM, Richard Hipp  wrote:
> 
> On 11/2/15, Jan Danielsson  wrote:
>> 
>>   Supporting symlinks on Windows would currently be a little mess.
> 
> What if we just say that symlinks don't work on Windows and that if
> you include them in your repo, you won't be able to checkout (sanely)
> on Windows?

I think Fossil should give a best-effort try via UAC, but yeah, if that doesn’t 
work, no tears should be shed about it.
___
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] Can't build Fossil 1.34 with Tcl 8.5

[Piotr Orzechowski]

Thanks, guys.

Adding --with-tcl-stubs and --with-tcl-private-stubs did not help.
I still get the:

bld/th_tcl.o: In function `evaluateTclWithEvents':
/fossil-src-1.34/./src/th_tcl.c:1069: undefined
reference to `Tcl_Canceled'
collect2: error: ld returned 1 exit status
make: *** [fossil] Błąd 1

That #define looks scary, to be honest. ;)

Pozdrawiam / With best regards,
Orzech

W dniu 02.11.2015 o 23:52, Joe Mistachkin pisze:
> Piotr Orzechowski wrote:
>> /fossil-src-1.34/./src/th_tcl.c:1069: undefined
>> reference to `Tcl_Canceled'
>> collect2: error: ld returned 1 exit status
>> make: *** [fossil] Error 1
>>
> Thanks for the report.  There are a couple workarounds:
>
>   1. use "--with-tcl-private-stubs=1" with configure.
>   2. #define Tcl_Canceled(a,b)  TCL_OK
>
> --
> Joe Mistachkin
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
W dniu 02.11.2015 o 23:50, Jan Nijtmans pisze:
> 2015-11-02 23:43 GMT+01:00 Piotr Orzechowski :
>> Hi,
>>
>> I can't build Fossil 1.34 with Tcl 8.5 (8.5.0-2.1) on fully up-to-date
>> Debian Wheezy 64-bit.
>>
>> I configure Fossil with:
>>
>> ./configure --prefix=/opt --with-openssl --with-tcl=/usr/lib/tcl8.5
>> --with-th1-hooks --json --with-zlib
> Just add the options --with-tcl-stubs and --with-tcl-private-stubs,
> then it will work fine. (Don't ask me why this isn't the default
> when using --with-tcl, I think it should be)
>
> Regards,
>  Jan Nijtmans
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] fossil v1.34 unexpected CLEAN command changes from v1.33

[tonyp]

I built the latest version and (unfortunately, for me) CLEAN no longer asks for 
confirmation.

Is this something I can have behave the way it was in v1.33 via some setting?  
(I often do a clean but may want to skip some file, so I like to be asked.)

If not possible anymore, is there at least some way to see which files get 
cleaned (other than running with –n option in advance which would require 
running the clean command twice all the time – and remembering about it) so I 
can undo the specific one I want to keep?

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

[Jan Danielsson]

On 03/11/15 00:00, Warren Young wrote:
> On Nov 2, 2015, at 3:56 PM, Richard Hipp  wrote:
>>
>> On 11/2/15, Jan Danielsson  wrote:
>>>
>>>   Supporting symlinks on Windows would currently be a little mess.
>>
>> What if we just say that symlinks don't work on Windows and that if
>> you include them in your repo, you won't be able to checkout (sanely)
>> on Windows?
> 
> I think Fossil should give a best-effort try via UAC, but yeah, if that 
> doesn’t work, no tears should be shed about it.

   Personally I don't think UAC is a viable solution.  Just imagine
having typed "fossil update" as an unprivileged user and it suddenly
says "Hey, I can see you want to perform potentially dangerous
administrative tasks -- are you sure you accept?".  I really don't think
it's reasonable for an unattended user to have to switch to
administrator mode for checking out/updating code.

   I don't know which is worse; not supporting symlinks at all on
Windows, or telling people that they need to have administrator
privileges on their system in order to check the code out (note: not
build, just to check the code out).

   Also; if anyone has automated/unattended build systems on Windows for
projects which have symlinks -- those checkouts/updates won't be able to
be unattended any longer, unless they want to change the build system to
run as administrator (which I would guess is a huge no-no in most cases).

   Like I wrote earlier, I think the symlink situation on Windows is too
messy currently.  I won't oppose anyone who gives the UAC route a shot,
but I think the feature will be way too flimsy on Windows -- it won't
look good, and I'd wager people who encounter these issues will blame
fossil for it.

   I think it's best to say Windows doesn't support symlinks for
unprivileged users, and fossil requires basic day-to-day operations to
work for unprivileged users, so it won't support symlinks on Windows
until they improve.

   With all that said -- I have no idea if things have changed to the
better on that front in Windows 10.

-- 
Kind Regards,
Jan
___
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

[Scott Robison]

On Mon, Nov 2, 2015 at 4:00 PM, Warren Young  wrote:

> On Nov 2, 2015, at 3:56 PM, Richard Hipp  wrote:
> >
> > On 11/2/15, Jan Danielsson  wrote:
> >>
> >>   Supporting symlinks on Windows would currently be a little mess.
> >
> > What if we just say that symlinks don't work on Windows and that if
> > you include them in your repo, you won't be able to checkout (sanely)
> > on Windows?
>
> I think Fossil should give a best-effort try via UAC, but yeah, if that
> doesn’t work, no tears should be shed about it.
>

I know I've posted this before, but just to reiterate:

If you are an unprivileged user, you can create symlinks if you've been
granted the symlink priv. It is not hard to do at all.

The problem comes with UAC for unelevated administrative users only,
because Microsoft in their infinite wisdom saw fit to strip symlink privs
from unelevated admin users by default.

One: Most windows users wouldn't be using symlinks and wouldn't care.

Two: It's not hard to have two command prompts open, one running as a non
admin user with symlink privs. One could run fossil from the non admin
user. Or one could easily run fossil as the non admin user that has symlink
privs.

Maybe it's not worth doing, and maybe I shouldn't have bothered adding real
symlink support in the winsymlink branch. However, it is possible, and it's
not as onerous as many people are making it out to be.

>From https://en.wikipedia.org/wiki/NTFS_symbolic_link#Restrictions: The
default security settings in Windows Vista/Windows 7
 disallow non-elevated
administrators and all non-administrators from creating symbolic links. *This
behavior can be changed running "secpol.msc" the Local Security Policy
management console (under: Security Settings\Local Policies\User Rights
Assignment\Create symbolic links). It can be worked around by starting
**cmd.exe
 with Run as administrator option or
the runas  command.*

-- 
Scott Robison
___
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] symlinks (was Re: xkcd on git)

[Ron W]

On Mon, Nov 2, 2015 at 1:16 PM, bch  wrote:
>
> Philosophically, I think of links as build artifacts, which are rarely
> stored in an scm. I do avoid them as much as possible, but I've
> occasionally wondered: does anybody manage the links as the build artifacts
> of a script, and keep the script itself under version control?
>
We used to, but now use the vpath directive in GNU make, so longer need
symlinks.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Can't build Fossil 1.34 with Tcl 8.5

[Piotr Orzechowski]

Hi,

I can't build Fossil 1.34 with Tcl 8.5 (8.5.0-2.1) on fully up-to-date
Debian Wheezy 64-bit.

I configure Fossil with:

./configure --prefix=/opt --with-openssl --with-tcl=/usr/lib/tcl8.5
--with-th1-hooks --json --with-zlib

And I then get the following from make:

/fossil-src-1.34/./src/th_tcl.c:1069: undefined
reference to `Tcl_Canceled'
collect2: error: ld returned 1 exit status
make: *** [fossil] Error 1

There was no such problem with Fossil 1.33 and there was no such problem
on Debian 8 Jessie with Tcl 8.6.

-- 

Pozdrawiam / With best regards,
Orzech




signature.asc
Description: OpenPGP digital signature
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] xkcd on git

[Warren Young]

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.

  https://www.google.com/?q=detached%20head%20state
___
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

[Jan Danielsson]

On 02/11/15 23:23, Warren Young wrote:
>> Windows will ultimately get decent symlink support.
> 
> I doubt it.  Microsoft has tried to take a bite of that apple twice, and 
> screwed it up both times.
> 
> First there was the Windows 95 *.lnk file feature, which is basically only a 
> symlink to Windows Explorer.
> 
> Then in Vista they finally added true symlinks, but only Admin users can 
> create them, and then only from within an Admin shell!  cmd.exe doesn’t know 
> how to temporarily auto-elevate itself via UAC, as with most other privileged 
> operations.  (There’s no reason that Windows builds of Fossil can’t do the 
> UAC dance, though.)

   There may be Reasons that only admins can do symlinks.  If you read
about reparse-points in the DDK you start to get the sense that it was
hooked on to another set of functions as a "Oh, look, we kind of get
this feature for free, but with some caveats".

   The Community could work around the problem by creating a service
which is responsible for creating the appropriate reparse-point, and
allow regular users to communicate with the service.  There's another
reason I think symlinks are limited to administrators for now, but it's
out of scope here.

   Anywho, back to more fossil-related matters..  I've tried to work in
support for handling (reading/parsing) Windows symlinks in a library,
and I encountered an interesting problem when attempting to do what
would be considered readlink() in unix -- the call sometimes hangs(!).
For seemingly no good reason.  A quick search yielded that I'm not the
only one seeing the problem; and last time I checked there had been no
activity from Microsoft regarding a fix.

   The work-around is to use the DDK and manually parse the reparse
point data manually (which is how I ended up browsing through the
reparse point parts of the DDK..).

   Supporting symlinks on Windows would currently be a little mess.  Not
only is it the admin-issue, but unless they fix that intermittent hang
bug, we'll require parts of the DDK and do some ugly low-level parsing
in order to parse the links.

-- 
Kind Regards,
Jan
___
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] Can't build Fossil 1.34 with Tcl 8.5

[Joe Mistachkin]

Piotr Orzechowski wrote:
>
> /fossil-src-1.34/./src/th_tcl.c:1069: undefined
> reference to `Tcl_Canceled'
> collect2: error: ld returned 1 exit status
> make: *** [fossil] Error 1
> 

Thanks for the report.  There are a couple workarounds:

1. use "--with-tcl-private-stubs=1" with configure.
2. #define Tcl_Canceled(a,b)  TCL_OK

--
Joe Mistachkin

___
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

[Ron W]

On Mon, Nov 2, 2015 at 6:38 PM, Scott Robison 
wrote:
>
> From https://en.wikipedia.org/wiki/NTFS_symbolic_link#Restrictions: The
> default security settings in Windows Vista/Windows 7
>  disallow non-elevated
> administrators and all non-administrators from creating symbolic links. *This
> behavior can be changed running "secpol.msc" the Local Security Policy
> management console (under: Security Settings\Local Policies\User Rights
> Assignment\Create symbolic links). It can be worked around by starting 
> **cmd.exe
>  with Run as administrator option or
> the runas  command.*
>

Where I work, we would to ask IT to modify the policy for us. Given how
many years it took of them having to install the specialized tools we in
Product Engineering need before IT agreed to grant us local admin privs, I
would expect similar.

I suppose runas could be used in BAT files (much like sudo can be).

But, as I said in another post, we have been able to get away from symlinks
by using the vpath feature of GNU make.
___
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 server

[Josef Frank]

On 02.11.2015 09:29:29 Jan Danielsson wrote:

On 01/11/15 13:30, Damien Sykes-Pendleton wrote:

I’m running Windows. I’m not personally running anything on port 80, though I 
get a blank web page (as opposed to a 404 or problem loading error) when I 
visit localhost.


I forget the name of the tool, but in there's a nifty tool for
Windows which can list all the ports and which process owns them.  I
think the tool is part of the Sysinternals Suite (a quick glance makes
me think it may be "PortMon", but I'm not sure).  If you can't figure it
out any other way, you could use that to find out who is hogging port 80.


Actually the mentioned program is part of Windows itself, call it with 
the "-b" option:


netstat -b


--
jf





___
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] fossil v1.34 unexpected CLEAN command changes from v1.33

[Richard Hipp]

On 11/2/15, to...@acm.org  wrote:
> I built the latest version and (unfortunately, for me) CLEAN no longer asks
> for confirmation.
>
> Is this something I can have behave the way it was in v1.33 via some
> setting?  (I often do a clean but may want to skip some file, so I like to
> be asked.)

I just added the "fossil clean -i" or "--prompt" option that forced a
prompt for each file.  Still in a branch.

>
> If not possible anymore, is there at least some way to see which files get
> cleaned (other than running with –n option in advance which would require
> running the clean command twice all the time – and remembering about it) so
> I can undo the specific one I want to keep?
>
> Thanks.
>


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

[Scott Robison]

On Mon, Nov 2, 2015 at 5:21 PM, Jan Danielsson 
wrote:

> On 03/11/15 00:38, Scott Robison wrote:
> >>> On 11/2/15, Jan Danielsson  wrote:
> 
>    Supporting symlinks on Windows would currently be a little mess.
> >>>
> >>> What if we just say that symlinks don't work on Windows and that if
> >>> you include them in your repo, you won't be able to checkout (sanely)
> >>> on Windows?
> >>
> >> I think Fossil should give a best-effort try via UAC, but yeah, if that
> >> doesn’t work, no tears should be shed about it.
> >>
> >
> > I know I've posted this before, but just to reiterate:
> >
> > If you are an unprivileged user, you can create symlinks if you've been
> > granted the symlink priv. It is not hard to do at all.
>
>Sure, but that means instructing people to change a system policy to
> be able to check out code in repositories which use symlinks.
>
>Unless we pop up a question "Do you want to reconfigure the system to
> allow symlinks?" if needed, that would be more acceptable to me, but how
> do we handle domain environments where GPO's are pushed out by the
> domain controller, and the user can't change that setting?
>

I agree that it is awkward. If it is necessary it can be done.


> > The problem comes with UAC for unelevated administrative users only,
> > because Microsoft in their infinite wisdom saw fit to strip symlink privs
> > from unelevated admin users by default.
>
>Agreed.
>
> > One: Most windows users wouldn't be using symlinks and wouldn't care.
>
>Agreed, again.
>
> > Two: It's not hard to have two command prompts open, one running as a non
> > admin user with symlink privs. One could run fossil from the non admin
> > user. Or one could easily run fossil as the non admin user that has
> symlink
> > privs.
>
>This may surprise some of you, but I can point to a large IT
> consultant firm with thousands of developers world-wide who do _not_
> have administrator privileges on their own systems.  They simply can't
> open elevated command line prompts, unless they are driver developers
> who have been given special privileges due to specific project requirement.
>

Note that those who have no administrator privs are not impacted by this
(as long as administrators are willing to give the create symlink priv to
the user). They don't even need UAC, just the priv.

   I agree it's a theoretical point in this specific discussion, but
> just reminding that being able to open up an elevated command prompt can
> actually be a luxury in some environments, so it's not a "catch all"
> solution in Windows.
>
> > Maybe it's not worth doing, and maybe I shouldn't have bothered adding
> real
> > symlink support in the winsymlink branch. However, it is possible, and
> it's
> > not as onerous as many people are making it out to be.
>
>My skepticism boils down to the fact that we can't make a general
> solution which will work smoothly everywhere[*].  Call it OCD if you
> will, but I think "We support symlinks on Windows, but not without
> policy changes to the system and not in these types of special
> environments." looks a little iffy, considering there are no such
> caveats on other platforms.
>

I think it is better to make it possible (if fossil is going to support
symlinks) than to make it impossible, even if it is awkward. I didn't have
a particular need for symlink support when I started working on it, I just
thought it was better to narrow the gap between what is possible in the two
environments.


>
>That said, like I said earlier, I don't object to anyone willing to
> give it a shot, and seeing as you already have done it, then there's no
> sense in me making the argument that it would be better to wait until
> symlinks on Windows are more polished.
>
>I am curious to know though how you get the reparse point, and if
> you've encountered those hangs.  I didn't know about the winsymlink
> branch, so I'll take a look.
>

It may need some work. I'm using a particular API available from Vista
later (with some assistance in making it a bit more clean).


>[*] In practical terms, as you say, more or less zero users (today)
> will encounter these problems.  As stated; to me it's more the asymmetry
> which bothers me.
>

Understandable. I really do prefer the approaches others have said (using
make files or scripts to ensure symbolic links are created as needed). But
if it is needed, I think it is better to provide the functionality than to
say "oh well, too bad, use some other product".

-- 
Scott Robison
___
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] symlinks (was Re: xkcd on git)

[Ron W]

On Mon, Nov 2, 2015 at 6:00 PM, bch  wrote:
>
> After I posted this, I thought a Makefile (still to manage actual
> symlinks) would be an improvement over a shell script; you're punting
> on symlinks completely (using VPATH). How has VPATH (or the previous
> shell script) treated you as a symlink manager/replacement ?
>

It works fine.

Of course, we also had to tell the compiler/linker to search those same
directories.

Example:
vpath %.c $(VCPATH)
vpath %.h $(VHPATH)

CCOPTS += $(VHPATH:%=-I%)

And yes, before we started using vpath, we managed symlinks in our
makefiles.
___
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] Can't build Fossil 1.34 with Tcl 8.5

[Joe Mistachkin]

Piotr Orzechowski wrote:
> 
> Adding --with-tcl-stubs and --with-tcl-private-stubs did not help.
> 

Did you try "make distclean" first?

>
> That #define looks scary, to be honest. ;) 
>

I wrote both the Tcl and Fossil code in question and I can personally assure
you that it is safe (also I just tried it myself).  Simply run "./configure"
with the desired arguments and then add the necessary line to "autoconfig.h"
before running "make".  You may need to run "make distclean" first if there
are compiled files from a previous attempt around.

--
Joe Mistachkin

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