Re: [fossil-users] xkcd on git

[Michal Suchanek]

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

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

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

So yes, there is some issue here.

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

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

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

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

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

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

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

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

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

Thanks

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

Re: [fossil-users] xkcd on git

[Michal Suchanek]

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

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


This is nice example of out of context quoting.

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

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

Thanks

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

Re: [fossil-users] xkcd on git

[Warren Young]

On Nov 3, 2015, at 5:59 AM, Michal Suchanek  wrote:
> 
> On 2 November 2015 at 20:40, Richard Hipp  wrote:
>> On 11/2/15, Michal Suchanek  wrote:
>>> 
>>> when you
>>> want to separate the changes you want to commit and changes you want
>>> to ... keep uncommitted to do more work on them this is quite
>>> useful. And don't tell me nobody ever mixes unrelated and possibly
>>> conflicting changes in the same working directory.
>> 
>> People do that.  But it is much more easily accomplished by simply
>> listing the files you want to commit on the "commit" command line.
> 
> Unless you have unrelated changes in the same file, of course.

I made a proposal on the list here recently for a feature that would let you 
extract pieces of a diff from the stash interactively.  That would give you the 
effect of cherrypicking individual changes with the git staging area without 
making it a mandatory step in every checkin.

I call the Git staging area “mandatory” because from the perspective of Fossil 
with autosync enabled — the default — it is not a necessary part of using a 
DVCS.

Obviously you can use Git without ever pushing, in which case everyday Git use 
looks a fair bit like everyday Fossil use.  But, if that’s a reasonable 
solution to the usability problem, one wonders why you aren’t just using a 
non-distributed VCS.

By keeping your local and remote repos in sync at every checkin via its 
autosync feature, Fossil gives you most of the the everyday usage simplicity of 
a non-distributed VCS while still being a DVCS.  Git keeps you constantly aware 
that your local repo and the remote one are frequently out of sync.

Git was designed with that as a *feature*, not as an unfortunate consequence of 
some other design decision.  It is so designed because in the Linux kernel 
development community, people often go off on their own tangents for days or 
months, then only later publish something they want others to take a look at.

That’s great if your developers are all intended to go off on solo tangents for 
extended stretches.  

Fossil, though, is designed for teams that actually work *together* on things.  
You can still go off on a tangent with a branch, if you want, but in normal 
use, even that is still visible to the others sync’d to that repo.  Private 
branches and such are available in Fossil, but they’re not the default, as with 
Git.

No one here is saying that Git can’t work, or is unusable.  What we’re arguing 
here are the consequences of the defaults.  Defaults matter.

>> you should not be checking-in untested changes.
>> The proper way to do incremental check-ins is to stash the whole lot,
>> then pull out individual pieces from the stash and test and commit
>> them separately.
> 
> And that's what the staging area allows for easily.

In my experience, finding that you’ve done a whole bunch of mutually unrelated 
work without checking in is the exception case.

It’s a sign of unclear thinking.  Your DVCS should not be designed to support 
unclear thinking through its primary user interfaces.  Your DVCS should be 
designed so that unclear thinking carries a consequence, to encourage you to 
think more clearly in the future.

Manually disentangling overlapping patches is that consequence, in Fossil’s 
case.

Fossil encourages frequent checkins.  When frequent checkins aren’t possible, 
it makes branching and merging easy, so you can isolate your unclear thinking 
while you clarify your solution.

>> Note that detached head state is impossible in Fossil and in most
>> other VCSs.  (Unsure about Hg.)
> 
> Detached head state is the state which you enter when you check out
> some random commit id…Any VCS can do that.

Nope:

mkdir tmp
cd tmp
f clone http://fossil-scm.org ~/fossil.fossil
f open ~/fossil.fossil
f up 485aa80625acdb # some random commit ID
echo '/* silly change */' >> src/shell.c
f ci

Result?  Error:

   would fork.  "update" first or use --allow-fork.

So no, Fossil does not enter detached head state when you try to check in 
something in the middle of a branch.

If you follow Fossil’s recommendation (“update” first) your change is merged 
into the tip of that branch, automatically if possible.  Then there is no 
problem.

If instead you force Fossil to accept the checkin with --allow-fork, you end up 
with a dual-tipped branch, which doesn’t lose information, because the forked 
branch is still attached to the rest of the Fossil tree.

Alternately, you can check your changes in with --branch, which is functionally 
the same as --allow-fork, except that the new branch has its own name from the 
start, so you don’t end up with a dual-tipped branch, the very thing Fossil is 
warning you about here.

Furthermore, committing while in detached head state in Git does not create a 
dual-tippped branch, as in Fossil.  It creates a free-floating branch, 
disconnected from everything else.  If you then 

Re: [fossil-users] xkcd on git

[Warren Young]

On Nov 3, 2015, at 3:16 PM, Michal Suchanek  wrote:
> 
> This is nice example of out of context quoting.

No, it’s an example of trimming quotes because it is only necessary to remind 
people what was being said, since it’s 2015 and we all have mailers with 
history scrollback features, so we can read the full quote if we need to.

Tell you what: give me a list of Fossil commands that produces a repo with a 
branch in “detached head” state.  Then you win.
___
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 Tue, Nov 3, 2015 at 7:59 AM, Michal Suchanek  wrote:
>
> On 2 November 2015 at 20:40, Richard Hipp  wrote:
> > But on the other hand, you should not be checking-in untested changes.
> > The proper way to do incremental check-ins is to stash the whole lot,
> > then pull out individual pieces from the stash and test and commit
> > them separately.
>
> And that's what the staging area allows for easily. You add and remove
> hunks from staging area until you like the split and commit the
> staging area at which point CI fires or you stash the remaining
> changes and run your tests. Or you just don't care, of course.
>

I have no trouble using Fossil's stash to do the same. Granted, I'm using
an external gui-diff tool. But wouldn't a dev using Git be using some kind
of "enhanced diff" tool, too?

$ fossil stash
$ fossil stash gdiff

Sometimes, it would be nice to specify which files to diff, but usually,
when I need to cherry pick changes, I want to review all the changes,
anyway.

Then I build and test, possibly fix, then commit. Then move on to pull out
the next set of changes.
___
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

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

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

[Michal Suchanek]

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

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

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

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

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

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

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

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

Thanks

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

Re: [fossil-users] xkcd on git

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

[Stephan Beal]

On Sat, Oct 31, 2015 at 10:19 PM, Matt Welland 
wrote:

> On Sat, Oct 31, 2015 at 1:47 PM, Stephan Beal 
> wrote:
>
>> On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland 
>> wrote:
>>
>>> BTW, to some extent it is ok for fossil to be opinionated software that
>>> strives to dictate how to do your work. However take that model very far
>>> and you quickly alienate people. Given that perspective, why would fossil
>>> care if someone chooses to commit a symlink that points outside their repo?
>>> Give that user some credit, presumably he or she has a good reason for
>>> doing what they are doing.
>>>
>>
>> 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).

The default behaviour I'd like to see is:
>
> fast:
> one readlink call, done!
>
> non-judgemental:
>  the link can point wherever you want, fossil need not even check
>
> simple:
>  store linkname as filename, result from readlink as file content, and
> a flag, i.e. symlink
>

i'm not even sure what the default behaviour is, to be honest - i avoid
symlinks like the plague in all SCMs. When symlinks are disabled in fossil,
they are (to the best of my knowledge) stored as small files holding the
resolved name of the link (the "simple" option you list here).


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

[Ron W]

On Sun, Nov 1, 2015 at 4:14 AM, Stephan Beal  wrote:

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

On MS Windows, that is how it has to be done. Symlinks require the user be
an admin and use a special command that is separately installed.
___
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

[Matt Welland]

On Sun, Nov 1, 2015 at 2:14 AM, Stephan Beal  wrote:

> On Sat, Oct 31, 2015 at 10:19 PM, Matt Welland 
> wrote:
>
>> On Sat, Oct 31, 2015 at 1:47 PM, Stephan Beal 
>> wrote:
>>
>>> On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland 
>>> wrote:
>>>
 BTW, to some extent it is ok for fossil to be opinionated software that
 strives to dictate how to do your work. However take that model very far
 and you quickly alienate people. Given that perspective, why would fossil
 care if someone chooses to commit a symlink that points outside their repo?
 Give that user some credit, presumably he or she has a good reason for
 doing what they are doing.

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

As I tried to describe originally recreating the link is done automatically
on Unix and on Windows a file containing the link pointer is created.


> 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).
>
> The default behaviour I'd like to see is:
>>
>> fast:
>> one readlink call, done!
>>
>> non-judgemental:
>>  the link can point wherever you want, fossil need not even check
>>
>> simple:
>>  store linkname as filename, result from readlink as file content,
>> and a flag, i.e. symlink
>>
>
> i'm not even sure what the default behaviour is, to be honest - i avoid
> symlinks like the plague
>

I used to take this same stance but I've softened a little as I can see
some genuine savings in time and effort where symlinks are used
*judiciously* in an SCM context.


> in all SCMs. When symlinks are disabled in fossil, they are (to the best
> of my knowledge) stored as small files holding the resolved name of the
> link (the "simple" option you list here).
>

That makes sense. I think fossil is very very close to doing exactly what I
think is best in this regard but the default of following links has been
very problematic in my experience.


>
>
> --
> - 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
>
>
___
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 Nov 1, 2015 6:09 PM, "Ron W"  wrote:
>
> On Sun, Nov 1, 2015 at 4:14 AM, Stephan Beal 
wrote:
>>
>> 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).
>
>
> On MS Windows, that is how it has to be done. Symlinks require the user
be an admin and use a special command that is separately installed.

1. There is a winsymlink branch. I haven't merged from trunk too recently,
but it does (as far as has been tested) provide equivalent symlink
processing for Windows.

2. Normal non admin users can create symlinks. Admin users in a non
elevated context cannot. Admin users in an elevated context can. There is a
way to tweak defaults to allow all to be able to create symlinks. Thank MS
for the inexplicable hoops admin users must jump through.
___
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

[Stephan Beal]

On Sat, Oct 31, 2015 at 6:27 AM, Michal Suchanek  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.

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

[Matt Welland]

Hmmm I'm in a loquacious sort of mood and this spiel got long so I'm
adding a summary blurb, I recommend read the blurb and skip the rest.

Summary:

Modest needs of a lone developer not doing branching etc. can be met with
file system based methodology. Even so IMHO an SCM is still a productively
booster once learned.

The full spiel:

It sounds to me that Scott's needs are modest. Keep snapshots though time,
very limited parallel development, most work constrained to a single host,
only one developer. Given these factors it is true that using the file
system for very simple version control is quite doable. For someone who has
*already* mastered a SCM the cognitive burden of tracking code using the
tool is much lower than the burden of doing that same work by hand as Scott
is doing. It is my experience that even a lone coder doing no branching and
working on only one host *still* will benefit hugely from using a tool.
This is especially true of fossil as the learning curve is relatively small
relative due to the reduced degrees of freedom, (e.g. branches, timeline
etc. will look the same in all clones) relative to similar tools.

I've tried working without an SCM in a few cases and it is a royal pain.
Add the desire to keep my laptop, two home development machines and my
internet exposed server in sync, the fact that I do parallel development
often to allow exploration, bug fixes to old versions etc. and the
frequency that I resort to things like bisect, it would be a massive hit to
give up fossil. Your personal mileage may of course vary.

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.
For most of us mortals the costs outweigh the benefits and the simpler
tool, fossil, is a huge productivity boost for small learning cost. The
other benefit git offers is impressive performance. How git can report
extras 2x faster than a Unix find command covering the same directory tree
and 10x faster than fossil is nothing short of amazing. For your average
project this is milliseconds vs tenths of a second and no one cares but if
you are working on large development trees with lots of detritus it becomes
tiresome and I've noticed developers avoiding doing a fossil extras. Aside:
I'm curious, does fossil stop at directories with no controlled files in an
extras scan? That alone would be a huge optimization and might explain how
git is faster than find.

Just my $0.02.

(i) Is fossil that much less arcane? Last I checked mv, cp and rm don't
work the same as Unix, an ongoing annoyance for my users, then there is the
bizarre choice to treat symlinks as files by default - does any other SCM
do that? This bit me *again* recently and I'm still grumpy about it

On Sat, Oct 31, 2015 at 9:45 AM, Scott Doctor  wrote:

>
> Which is why I like my process. Redundancy is good. Not dependent on some
> algorithm to piece things back together. Disks are so frikkin large now
> that it is not an issue to have multiple copies of the same file. If one
> set gets corrupted, just use the one behind it. Fully self contained
> archived snapshots not needing any program to access it.
>
> 
> Scott Doctor
> sc...@scottdoctor.com
> --
>
> On 10/31/2015 1:53 AM, Stephan Beal wrote:
>
>> On Sat, Oct 31, 2015 at 6:27 AM, Michal Suchanek > > 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.
>>
>> --
>> - 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
>>
>
> ___
> 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] xkcd on git

[Stephan Beal]

On Sat, Oct 31, 2015 at 6:45 PM, Matt Welland 
wrote:

> Modest needs of a lone developer not doing branching etc. can be met with
> file system based methodology. Even so IMHO an SCM is still a productively
> booster once learned.
>

+1


> s quite doable. For someone who has *already* mastered a SCM the cognitive
> burden of tracking code using the tool is much lower
>

"mastered" ==> "learned the basic commands/functioning of"


> I've tried working without an SCM in a few cases and it is a royal pain.
>

+1


> Add the desire to keep my laptop, two home development machines and my
> internet exposed server in sync, the fact that I do parallel development
> often to allow exploration, bug fixes to old versions etc. and the
> frequency that I resort to things like bisect, it would be a massive hit to
> give up fossil.
>

+1

The initial feature which attracted me to fossil was CGI, which allowed me
to trivially sync over my $5/month web/mail hoster.


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

+ a few grey hairs ;)


> For most of us mortals the costs outweigh the benefits and the simpler
> tool, fossil, is a huge productivity boost for small learning cost.
>

+1


> The other benefit git offers is impressive performance. How git can report
> extras 2x faster than a Unix find command covering the same directory tree
> and 10x faster than fossil is nothing short of amazing. For your average
> project this is milliseconds vs tenths of a second and no one cares but if
> you are working on large development trees with lots of detritus it becomes
> tiresome and I've noticed developers avoiding doing a fossil extras.
>

fwiw, i have never once used 'extras,' neither on small nor large trees. i
see no need for it. (ymmv.)


> Aside: I'm curious, does fossil stop at directories with no controlled
> files in an extras scan? That alone would be a huge optimization and might
> explain how git is faster than find.
>

That's certainly a reasonable hypothesis.


> (i) Is fossil that much less arcane? Last I checked mv, cp and rm don't
> work the same as Unix, an ongoing annoyance for my users, then there is the
> bizarre choice to treat symlinks as files by default - does any other SCM
> do that? This bit me *again* recently and I'm still grumpy about it
>

fwiw, i have always been against the idea of fossil supporting symlinks at
all, despite me being a 100% unix user, simply because they aren't portable
and they open up philosophical cans of worms like how to hand links leading
outside the repo root. i _never_ use symlinks in any SCM. Support for the
+x bit (also not portable) was added relatively late, and primarily (only?)
to accommodate the convention of having an executable ./configure script.
(Not having executable scripts was really annoying.)

Happy Halloween,

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

[Gour]

On Sub, 2015-10-31 at 14:21 +0100, Jan Danielsson wrote:

>    No.  I had a checkout of a repository which was working fine.  One
> day I suddenly couldn't do things I have been doing all along with it
> (uncomplicated daily tasks; pull, commit, merge); git told me that my
> repository was broken.  I googled for the error, found a stackexchange
> question about the error message and a few of the replies where along
> the line of "Yeah, that randomly happens sometimes, just type these
> commands and it'll fix it." (no explanation, just "the word on the
> street is that these commands help").  I copy-n-pasted the commands,
> git did some work on the repository and it fixed the problem (as far
> as I could tell).

Yesterday I did chat with one of the main devs of quite popular/mature
open-source project and he confirmed having gripes with Git...

I did mention Fossil and he liked it, but due to project using Git, he
expressed interest to have fossil-git ala git-svn, so that would be
killer feature - allowing people to use Fossil with Git-based
projects!!1

Of course, I'm aware about differences in design...


Sincerely,
Gour

-- 
Not by merely abstaining from work can one achieve freedom 
from reaction, nor by renunciation alone can one attain perfection.


___
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

[Matt Welland]

On Sat, Oct 31, 2015 at 11:33 AM, Stephan Beal 
wrote:

> On Sat, Oct 31, 2015 at 6:45 PM, Matt Welland 
> wrote:
>
>
[snip]


> (i) Is fossil that much less arcane? Last I checked mv, cp and rm don't
>> work the same as Unix, an ongoing annoyance for my users, then there is the
>> bizarre choice to treat symlinks as files by default - does any other SCM
>> do that? This bit me *again* recently and I'm still grumpy about it
>>
>
> fwiw, i have always been against the idea of fossil supporting symlinks at
> all, despite me being a 100% unix user, simply because they aren't portable
> and they open up philosophical cans of worms like how to hand links leading
> outside the repo root. i _never_ use symlinks in any SCM. Support for the
> +x bit (also not portable) was added relatively late, and primarily (only?)
> to accommodate the convention of having an executable ./configure script.
> (Not having executable scripts was really annoying.)
>

In the electronic design industry symlinks are used extensively in SCM
controlled areas. Most often this allows omitting a build step where the
controlled files are scripts or other plain text data. Without good symlink
support fossil is eliminated from consideration. In supporting a cross
platform tool I think it is better to degrade gracefully rather than simply
design for the lowest common denominator. Windows will ultimately get
decent symlink support. Why not be ready for it with good support in fossil?

Symlinks can be meaningfully viewed as a special file, handled internally
as a one line text file, implemented on disk as a symlink where supported
or as a one-line file where not supported. Conceptually it is not that
complicated.

The default in fossil to follow symbolic links is hugely problematic. It is
impossible for fossil to automatically reproduce an originating working
area which was constructed by symlinking different areas on disk to a
single directory structure. Given that to recreate the original structure
manual effort is required after clone/open, this model makes no general
sense in the context of an SCM and should not be the default. Making
following symlinks available as an option is great and could be useful for
some use cases. But as a default it severely violates the principle of
least surprise for Unix users, at least in my professional experience. BTW,
as best I can tell git by default treats symlinks as symlinks and does not
support following links at all.

BTW, to some extent it is ok for fossil to be opinionated software that
strives to dictate how to do your work. However take that model very far
and you quickly alienate people. Given that perspective, why would fossil
care if someone chooses to commit a symlink that points outside their repo?
Give that user some credit, presumably he or she has a good reason for
doing what they are doing.

Happy Halloween,
>

Indeed! Happy Halloween!


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

[Matt Welland]

On Sat, Oct 31, 2015 at 1:47 PM, Stephan Beal  wrote:

> On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland 
> wrote:
>
>> BTW, to some extent it is ok for fossil to be opinionated software that
>> strives to dictate how to do your work. However take that model very far
>> and you quickly alienate people. Given that perspective, why would fossil
>> care if someone chooses to commit a symlink that points outside their repo?
>> Give that user some credit, presumably he or she has a good reason for
>> doing what they are doing.
>>
>
> 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.

The default behaviour I'd like to see is:

fast:
one readlink call, done!

non-judgemental:
 the link can point wherever you want, fossil need not even check

simple:
 store linkname as filename, result from readlink as file content, and
a flag, i.e. symlink




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

[Stephan Beal]

On Sat, Oct 31, 2015 at 9:41 PM, Matt Welland 
wrote:

> BTW, to some extent it is ok for fossil to be opinionated software that
> strives to dictate how to do your work. However take that model very far
> and you quickly alienate people. Given that perspective, why would fossil
> care if someone chooses to commit a symlink that points outside their repo?
> Give that user some credit, presumably he or she has a good reason for
> doing what they are doing.
>

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.

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

[Jan Danielsson]

On 31/10/15 06:27, Michal Suchanek wrote:
[---]
>> (For instance, my recent thread about how to clip off a a branch via the 
>> command line when the UI can’t do it because it was created empty, something 
>> Fossil can’t do, but which apparently CVS or SVN can, so it got into my 
>> Fossil tree when I converted.)
>>
>> This as compared to the sentiment in the XKCD comment, where if Git screws 
>> up, it’s often simpler to just toss the checkout and start over than try to 
>> recover.
> 
> Seriously, how do you screw up like this with git?
> 
> Unless you delete .git your checkout is always in well defined state.

   No.  I had a checkout of a repository which was working fine.  One
day I suddenly couldn't do things I have been doing all along with it
(uncomplicated daily tasks; pull, commit, merge); git told me that my
repository was broken.  I googled for the error, found a stackexchange
question about the error message and a few of the replies where along
the line of "Yeah, that randomly happens sometimes, just type these
commands and it'll fix it." (no explanation, just "the word on the
street is that these commands help").  I copy-n-pasted the commands, git
did some work on the repository and it fixed the problem (as far as I
could tell).

   To your point though: Those who replied seemed to think this was
normal, so I guess one could argue that error is a "well defined state".

   I was about to just delete my checkout and start again, but I was
curious to see if anyone else had encountered it.

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

Which is why I like my process. Redundancy is good. Not 
dependent on some algorithm to piece things back together. Disks 
are so frikkin large now that it is not an issue to have 
multiple copies of the same file. If one set gets corrupted, 
just use the one behind it. Fully self contained archived 
snapshots not needing any program to access it.



Scott Doctor
sc...@scottdoctor.com
--

On 10/31/2015 1:53 AM, Stephan Beal wrote:
On Sat, Oct 31, 2015 at 6:27 AM, Michal Suchanek 
> 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.


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


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

Git does a perfectly awful job of minimizing the amount of state that
the developer must remember.  With the possible exception of
ClearCase, I don't know of any other VCS that requires the user to
remember as much state as does Git.  And since this extra state
detracts from solving the problem at hand, that makes Git a bad VCS,
in my opinion.

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

[Andy Bradford]

Thus said Scott Doctor on Sat, 31 Oct 2015 09:45:07 -0700:

> Which is why  I like my process. Redundancy is  good. Not dependent on
> some algorithm  to piece  things back together.  Disks are  so frikkin
> large now that it is not an  issue to have multiple copies of the same
> file. If  one set gets  corrupted, just use  the one behind  it. Fully
> self contained  archived snapshots not  needing any program  to access
> it.

Do you  find it easy to  rationalize changes in this  fashion? I suppose
you can use standard tools like diff to show differences, but how to you
keep track of chronological events?

Have you had a look at  ClearCase's MVFS (multi version file system) and
VOBs?

Thanks,

Andy
-- 
TAI64 timestamp: 400056357366


___
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 Matt Welland on Sat, 31 Oct 2015 10:45:33 -0700:

> The other  benefit git offers  is impressive performance. How  git can
> report extras  2x faster than  a Unix  find command covering  the same
> directory tree and 10x faster than fossil is nothing short of amazing.

One of the most  annoying things that I deal with every  day is how long
git takes the first  time I use it. The first time I  do ``git pull'' or
``git status'' in one of the repositories I work with is deplorable.

I guess it depends on a lot of factors.

Andy
-- 
TAI64 timestamp: 400056357460


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

I did not say I did not use version control. By VCS I refer to 
the programs such as fossil, git, mercurial... used for doing 
such. I am using Fossil for my current project in parallel with 
my own way of handling versions. Embarcadero RAD Studio 
incorporates Git, Mercurial, and Subversion into the IDE. Had 
issues with them, so I tried fossil. Still evaluating its utility.


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. 
Especially when new to the system, a GUI interface is much 
better than having to work with yet another list of command line 
formats.


I fully see the utility of a VCS on collaborative projects. My 
project is for my own research work and is not used by any 
clients. I am also the only one who plays with my code. So some 
of the utility needed for collaborative efforts becomes 
cumbersome for a solo project.


I have a directory tree on various backup drives of my old 
versions, one-off programs, and a huge library of my own 
utilities. The development system I use (Embarcadero RAD Studio) 
has a built-in program manager which juggles the various files 
required for the build.


Before I start writing a new function, process, or other 
modification, I create a sub-folder of my backup folder which 
are numbered in sequence. The file system applies a date to the 
creation time of the folder which identifies when the backup was 
made. I then simply copy my entire project folder into the 
backup folder. If I break the code, or decide to revert the 
changes, I restore the project from the desired backup folder. 
This is a bit cumbersome way of handling versions, especially 
given my main program consists of more than 250 files. Such is 
why I am trying out various VCS systems. I am finding them just 
as cumbersome of a process with an added layer of things to go 
wrong.



Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 12:59 PM, Richard Hipp wrote:

On 10/30/15, Scott Doctor  wrote:

That is my experience with all VCS systems. Even with fossil, I
am having trouble justifying why the hassle is worth the effort.


What do you do when a customer calls to ask about code you sent them
18 months ago?  How do you figure out what version of the code they
are running?

When you find an obscure bug that you know was not in the release from
December 2012 but might have been introduced anytime between then and
now, how do you figure out when it was introduced?

How do you add experimental features and make experimental changes?
Do you just start hacking away and hope the changes don't break
anything?

How do you identify versions of your code to your customer?

How do you verify that no stray changes have been introduced into your code?

How do you backup your code?

When you have multiple people collaborating on the same project, how
do you coordinate their changes and ensure that features added by one
developer don't get overwritten and erased by another developers.  How
do you know who is working on what?  Can you even identify what you
code is?

Seriously.  I don't understand how it is possible to make reliable
software without good version control.  Is the foundation of
everything.




___
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

[sky5walk]

​"​
Even with fossil, I am having trouble justifying why the hassle is worth
the effort.
​"
​
Sorry, but the alternatives
​(I have a Halloween shudder at the thought)​

​are way more effort in the long run.​
I agree, merging is difficult when there are conflicts. But, Fossil and
others show your options to proceed. You are in control.

On Fri, Oct 30, 2015 at 4:08 PM, jungle Boogie 
wrote:

> On 30 October 2015 at 10:56, Scott Doctor  wrote:
> > That is my experience with all VCS systems. Even with fossil, I am having
> > trouble justifying why the hassle is worth the effort.
>
>
> I version control config files for apps, .vimrc files, and small
> scripts just so I can see what changes I make between them and for
> faster setup on new machines. In my very simple setup, I see clear
> benefits of using version control (Fossil and rcs) on these files. I
> can't imagine how serious software dev would work without some form of
> version control.
>
> --
> ---
> 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
>
___
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 2:37 PM, Scott Doctor  wrote:
> 
> Embarcadero RAD Studio incorporates Git, Mercurial, and Subversion into the 
> IDE.

Yes, it would be nicer if more IDEs had Fossil plugins.

That said, I always have a terminal window up, cd’d into the project, so even 
when using something like Visual Studio, a quick Alt-Tab and “f ci” is no 
trouble.

> What I meant was I end up spending much time trying to get the tools to do 
> what I want it to do versus how it wants to do it.

Examples, please.

> I fully see the utility of a VCS on collaborative projects. My project is for 
> my own research work and is not used by any clients. I am also the only one 
> who plays with my code. So some of the utility needed for collaborative 
> efforts becomes cumbersome for a solo project.

I’ve used Fossil for solo work, and it’s still greatly preferable to the 
alternatives.  In addition to drh’s points:

1. Multi-machine sync.  I view laptop computers as a compromise, something to 
use when you can’t use a desktop computer.  Since I can’t always restrict my 
coding activities to a single location, that means I occasionally have to sync 
my work to a laptop, or between two different desktops.  Fossil does that, and 
does so in a much easier fashion than other DVCSes.  (f all sync!)

Dropbox and such are poor alternatives, since I don’t want my object files and 
executables sync’d to the cloud, and I don’t want to see a throbby little icon 
in the corner of my vision every time I save a file.  I want to batch my syncs 
up, do them on my schedule, and send only source files, no object files.

2. Deduplication.  Your versioning scheme requires needless copies of unchanged 
files.  Fossil only stores what is needful, which means I can download the 
entire history of a project without even thinking about it.

I suspect if you checked all the past versions of your system into a single 
Fossil repo, it would be about the size of 3 or 4 of your existing “whole 
project” archives.  So, you’ve got a choice: in the same bandwidth/disk space 
as a handful of archives, you can have all the history, or just the most recent 
history.

3. Comments.  I used to keep a paper log book of the things I was working on, 
so I could go back later and figure out what I did and why.  Searching the 
comment stream of a Fossil timeline is far better.

4. Wiki and technotes.  When I have too much to say to fit into a comment box, 
I can write an article about it, which gets sync’d to my various development 
machines.

5. Tickets.  I used to keep a Wishlist or TODO file in each project, containing 
the things I wanted to do next.  Tickets do that better, since you can 
prioritize them, search them, reference them from checkin comments and wiki 
articles, etc.

You can have my Fossil after I *become* a fossil. :)

> Before I start writing a new function, process, or other modification, I 
> create a sub-folder of my backup folder which are numbered in sequence. The 
> file system applies a date to the creation time of the folder which 
> identifies when the backup was made. I then simply copy my entire project 
> folder into the backup folder.

This is easier than “fossil ci --tag v1.2.3” or “fossil ci --branch 
expermental-feature”?

For solo projects, branch merging is nearly trivial, since the chances of 
colliding changes is near-zero.

And if you do find yourself changing the same area of code on two different 
branches, it’s easy to say something like “f merge trunk” from the branch to 
sync changes made in the trunk into the experimental branch, so you can 
overwrite some of the recent trunk changes without confusing Fossil.

> If I break the code, or decide to revert the changes, I restore the project 
> from the desired backup folder.

That’s easier than “f up trunk” to toss a bad branch, or “f revert” to toss 
uncommitted changes, or “f up v1.2.3” to roll back to a prior stable version?

> I am finding them just as cumbersome of a process with an added layer of 
> things to go wrong.

I rarely find Fossil failing in ways I can’t understand.  And every time it has 
happened, someone on the list has explained it.

(For instance, my recent thread about how to clip off a a branch via the 
command line when the UI can’t do it because it was created empty, something 
Fossil can’t do, but which apparently CVS or SVN can, so it got into my Fossil 
tree when I converted.)

This as compared to the sentiment in the XKCD comment, where if Git screws up, 
it’s often simpler to just toss the checkout and start over than try to recover.

Another example is the “double tip” stuff we’ve seen on the list.  Fossil now 
diagnoses that problem, allowing you to correct it before it becomes a serious 
problem.

For the most part, Fossil obeys the principle of least astonishment.

Maybe that’s because I’ve been conditioned by ~15 years of CVS and SVN, so I 
know how VCSses are supposed to work.  If so, this is where we need your 

Re: [fossil-users] xkcd on git

[Stephan Beal]

On Oct 30, 2015 21:37, "Scott Doctor"  wrote:
>
>
> 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.

i would argue that that's backwards (and possibly the source of your
frustration with SCM). Software is designed to work a certain way, not
necessarily be bent to work how one wants it to. No word processor works
how i _want_ it to, yet there is not much i can do about that. That doesn't
decrease their utility if i adjust my expectations to how they are intended
to work.

- stephan
(Sent from a mobile device, possibly from bed. Please excuse brevity,
typos, and top-posting.)
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] xkcd on git

[Michal Suchanek]

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

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

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

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

>
> (For instance, my recent thread about how to clip off a a branch via the 
> command line when 

Re: [fossil-users] xkcd on git

[Stephan Beal]

On Fri, Oct 30, 2015 at 6:05 PM, Eric Rubin-Smith  wrote:

> I suspect Fossil folks will appreciate this :-)
>
> http://xkcd.com/1597/
>
>
http://fossil-scm.org/index.html/info/227b837a6c686972

:)


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

[fossil-users] xkcd on git

[Eric Rubin-Smith]

I suspect Fossil folks will appreciate this :-)

http://xkcd.com/1597/

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

[Gour]

On Pet, 2015-10-30 at 21:33 +0300, Konstantin Khomoutov wrote:

> I'm a programmer, and after having used a bunch of centralized and
> distributed VC systems I've come to a temporary conclusion that the
> set of problems [D]VC systems are trying to solve has certain
> irreducible complexity, and hence these systems either throw it onto
> the heads of the users (Git) or sweep it under the rug (Mercurial,
> Fossil).

I do use Fossil for *all* my private projects and intend to use it for
open-source one as well...however, in my experience using different
(D)VCS, I still believe that Darcs was the easiest one to use, but, it
had some peformance problems as well as lack of reliable public
hosting.


Sincerely,
Gour

-- 
Many, many births both you and I have passed. I can remember 
all of them, but you cannot, O subduer of the enemy!


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

It is sort of the "Lightbulb Problem":

Scenario 1: I want to design a lightbulb. So I study metallurgy, 
thermodynamics, electronics, manufacturing processes... Study 
what others succeded/failed at,... and so forth.


Scenario 2: I want to use that lightbulb in my project. I only 
need to study a subset, or simply how to wire it up from the manual.


Sceanario 3: I want to turn on the light bulb.


Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 11:44 AM, Gour wrote:

On Pet, 2015-10-30 at 21:33 +0300, Konstantin Khomoutov wrote:


I'm a programmer, and after having used a bunch of centralized and
distributed VC systems I've come to a temporary conclusion that the
set of problems [D]VC systems are trying to solve has certain
irreducible complexity, and hence these systems either throw it onto
the heads of the users (Git) or sweep it under the rug (Mercurial,
Fossil).

I do use Fossil for *all* my private projects and intend to use it for
open-source one as well...however, in my experience using different
(D)VCS, I still believe that Darcs was the easiest one to use, but, it
had some peformance problems as well as lack of reliable public
hosting.


Sincerely,
Gour



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

That is my experience with all VCS systems. Even with fossil, I 
am having trouble justifying why the hassle is worth the effort.



Scott Doctor
sc...@scottdoctor.com
--

On 10/30/2015 10:07 AM, Stephan Beal wrote:
On Fri, Oct 30, 2015 at 6:05 PM, Eric Rubin-Smith 
> wrote:


I suspect Fossil folks will appreciate this :-)

http://xkcd.com/1597/


http://fossil-scm.org/index.html/info/227b837a6c686972

:)

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


___
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

[Konstantin Khomoutov]

On Fri, 30 Oct 2015 10:56:48 -0700
Scott Doctor  wrote:

> That is my experience with all VCS systems. Even with fossil, I 
> am having trouble justifying why the hassle is worth the effort.

I'm honestly not flame-baiting but have you tried to come up with an
interface idea/sketch/set of paradigms that would considerably lower
the barrier for people to use DVC systems?

No, really, even those rare programmers who are able to reason about
the ways their software is used like "mere mortals" are skewed in their
reasoning.

I'm a programmer, and after having used a bunch of centralized and
distributed VC systems I've come to a temporary conclusion that the set
of problems [D]VC systems are trying to solve has certain irreducible
complexity, and hence these systems either throw it onto the heads of
the users (Git) or sweep it under the rug (Mercurial, Fossil).

So it would be really interesting to see some *constructive* discussion
of different approaches such systems should take when making their
users tackle that set of problems.
___
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 10/30/15, Scott Doctor  wrote:
>
> That is my experience with all VCS systems. Even with fossil, I
> am having trouble justifying why the hassle is worth the effort.
>

What do you do when a customer calls to ask about code you sent them
18 months ago?  How do you figure out what version of the code they
are running?

When you find an obscure bug that you know was not in the release from
December 2012 but might have been introduced anytime between then and
now, how do you figure out when it was introduced?

How do you add experimental features and make experimental changes?
Do you just start hacking away and hope the changes don't break
anything?

How do you identify versions of your code to your customer?

How do you verify that no stray changes have been introduced into your code?

How do you backup your code?

When you have multiple people collaborating on the same project, how
do you coordinate their changes and ensure that features added by one
developer don't get overwritten and erased by another developers.  How
do you know who is working on what?  Can you even identify what you
code is?

Seriously.  I don't understand how it is possible to make reliable
software without good version control.  Is the foundation of
everything.


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

[jungle Boogie]

On 30 October 2015 at 10:56, Scott Doctor  wrote:
> That is my experience with all VCS systems. Even with fossil, I am having
> trouble justifying why the hassle is worth the effort.


I version control config files for apps, .vimrc files, and small
scripts just so I can see what changes I make between them and for
faster setup on new machines. In my very simple setup, I see clear
benefits of using version control (Fossil and rcs) on these files. I
can't imagine how serious software dev would work without some form of
version control.

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