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

[Graeme Pietersz]

I also find symlinks useful for similar reasons - although I do not use
nested repos, so my usage is simpler.

It does become a problem when I work with someone who uses Windows and 
can see that is harder to fix. Would it not be possible for Fossil to
detect whether the user can create symlinks or not, and then create a
symlink if possible? Perhaps add a Windows specific option to choose
between this and the current behaviour?


On 04/11/15 00:29, David Mason wrote:
> On 3 November 2015 at 10:48, Eric Rubin-Smith  > wrote:
>
>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal
> mailto:sgb...@googlemail.com>> wrote:
>
> i can't speak for Richard, but if i had my way, fossil
> wouldn't support symlinks at all.
>
>
> This would force me to stop using Fossil (or at least updating to a
> version that didn't support them), and to recommend to everyone
> (including the hundreds of students who I've introduced to Fossil) to
> be wary using it.
>
> Part of the problem in this discussion is that everyone seems to be
> assuming that Fossil is only used for source trees and makefiles.  I
> maintain a dozen web sites, a few of them are my course-based ones.  I
> have (simplified for expository purposes) let's say 3 repos: Courses,
> cps710 and cps506.  Courses has sub-directories Themes (for CSS, etc.)
> and JScript.  cps710 and cps506 are nested under Courses, so the
> structure looks like:
> Courses
>Themes
>JScript
>cps710
>  Themes -> ../Themes
>  JScript -> ../JScript
>  f2013
>   index.html
>   f2013 -> .
>   current -> ../current
>   Themes -> ../Themes
>   JScript -> ../JScript
>  f2015
>   index.html
>   f2015 -> .
>   current -> ../current
>   Themes -> ../Themes
>   JScript -> ../JScript
>  current -> f2015
>  index.html -> current/index.html
>cps506
>  Themes -> ../Themes
>   JScript -> ../JScript
>  index.html -> current/index.html
> etc.
>
> So symlinks, with nested repos is a huge win for me.  Fortunately, I
> only need to set up a new course occasionally, so I only have to fight
> with Fossil about symlinks occasionally, but too often!
>
> The poor support for symlinks is far and away my biggest complaint
> with Fossil. (The limited support for file permissions is second,
> because I often want to put things in the repo that I'm not ready to
> show the students yet.)
>
> It's simple: a symlink is a filesystem artifact and should be
> reflected as such in the repository.  It should not be followed; if
> foo is a symlink and I say "fs add foo/bar" it should probably give an
> error. (This might surprise people the first time, but it's easy to
> explain - foo/bar isn't part of the repo, regardless of where foo points.)
>  
>
> :-) Fossil creates a problem by not supporting symlinks properly,
> and you use the volume of complaints about the problem to support
> your claim that the problem was inevitable.
>
> Not implementing them at all, or implementing them poorly as
> Fossil has, is what maximizes complaints -- hence the large amount
> of emails.
>
>
> Exactly.  Please fix symlinks so that if you live only on Unix you get
> seamless support.  If you work back and forth between Windows and Unix
> then you probably just don't use symlinks, so it won't be a problem
> for you! 
>
> ../Dave
>
>
> ___
> fossil-users mailing list
> fossil-users@lists.fossil-scm.org
> http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

-- 
Graeme Pietersz
http://moneyterms.co.uk/
http://pietersz.net/

___
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] handling backports

[jungle Boogie]

On 3 November 2015 at 15:14, Richard Hipp  wrote:
>
> That is exactly what --cherrypick is for.
>
> You can see a couple of recent examples of this in the SQLite source
> tree, where we took a couple bug fixes from trunk and
> cherrypick-merged them into the branch-3.9 branch to create the recent
> 3.9.2 release.


Do you think the --cherrypick option deserves a little info about it
or is it self explanatory with what's written?
https://www.fossil-scm.org/index.html/help?cmd=merge

Except, if either of the --cherrypick or
--backout options are used only the changes associated with the
single check-in VERSION are merged.



-- 
---
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Re: [fossil-users] 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

[fossil-users] [patch] Default skin, show Release Version

[Lonnie Abelbeck]

Hi,

At a quick glance there does not seem any way to determine the Fossil Release 
Version from the web interface.

It seems some skins show the Release Version in the footer, and some do not.  I 
would like to request the default skin to do so as per this trivial patch...

@@ -1,6 +1,6 @@
 
 This page was generated in about
 puts [expr {([utime]+[stime]+1000)/1000*0.001}]s by
-Fossil version $manifest_version $manifest_date
+Fossil v$release_version $manifest_version $manifest_date
 
 


resulting in a footer:
--
This page was generated in about 0.016s by Fossil v1.34 [62dcb00e68] 2015-11-02 
17:35:44
--

Then I have a question, to make the above patched "skin" work, it seems Fossil 
caches the default skin when the repo is created, and Fossil is smart enough to 
determine if the cached skin differs from the new version of the skin and you 
have to manually install the new (patched) skin.  Am I understanding this 
correctly ? 

Lonnie

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

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

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> Version [aa92270fe9] seems to have regressed the case of opening a
repository with a
> .fossil-checkout/allow-symlinks file set to 'on'.  See the transcript
below.  Note
> that I had created the repository earlier (I assume this does not matter
for the
> purposes of this test).

This issue was more subtle than it originally appeared.  I think the current
trunk
changes should make it work right for both versioned and non-versioned
allow-symlinks
settings.

--
Joe Mistachkin

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

Re: [fossil-users] handling backports

[Richard Hipp]

On 11/3/15, Warren Young  wrote:
> On Nov 3, 2015, at 11:48 AM, Eduard  wrote:
>>
>> Scenario 1: Suppose a really terrible bug (e.g. an exploitable
>> vulnerability) is discovered. Although the latest release is version
>> 2.47, it affects every version from 2.12 onwards. Trunk gets quickly
>> patched and a new minor version 2.47.1 is released. However, most users
>> are still using versions 2.35 and 2.43, and they can't necessarily
>> upgrade to 2.47 (e.g. because of some new library dependency that was
>> introduced, or some breaking change). What is the correct way of
>> handling this in Fossil (or in a DVCS in general)?
>
> Cherrypick the patch, apply it to the 2.35 and 2.43 branches, and release
> the tips of those branches as 2.35.1 and 2.43.1.
>
> Fossil might be able to do most of this work for you via “fossil merge
> --cherrypick”.  Try it.
>

That is exactly what --cherrypick is for.

You can see a couple of recent examples of this in the SQLite source
tree, where we took a couple bug fixes from trunk and
cherrypick-merged them into the branch-3.9 branch to create the recent
3.9.2 release.

Example 1:

  https://www.sqlite.org/src/timeline?c=dab0e607&y=ci

You can see that this commit is a cherrypick of the chronologically
previous commit that is one trunk.  The commands to do this were:

  fossil update branch-3.9
  fossil merge --cherrypick trunk# because at the time
db319a03 was head of trunk
  # test the changes
  fossil commit

When doing the commit, you'll notice that Fossil automatically fills
in the commit comment to be the same as the comment on the commit that
was cherrypicked.

The second example is:

  https://www.sqlite.org/src/timeline?c=c0c4b6b3&y=ci

Which is a cherrypick of an earlier change at

  https://www.sqlite.org/src/timeline?c=bfea226d&y=ci
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 4:51 PM, Joe Mistachkin 
wrote:

>
> Eric Rubin-Smith wrote:
> >
> > (1) Default allow-symlinks to true
> > (2) Fix bug in which the allow-symlinks setting is not honored while
> > opening a repository
> >
>
> Please try the latest Fossil trunk and let us know if that fixes all the
> issues you were seeing.
>
>
Version [aa92270fe9] seems to have regressed the case of opening a
repository with a .fossil-checkout/allow-symlinks file set to 'on'.  See
the transcript below.  Note that I had created the repository earlier (I
assume this does not matter for the purposes of this test).

[little:test] $ fossil version
This is fossil version 1.34 [aa92270fe9] 2015-11-03 22:09:23 UTC
[little:test] $ fossil set
access-log
admin-log
allow-symlinks
auto-captcha
{snip}
[little:test] $ mkdir sandbox
[little:test] $ cd sandbox/
[little:sandbox] $ fossil open ../foo.db
.fossil-settings/allow-symlinks
foo
foo.lnk
project-name: 
repository:   /home/eas/tmp/test/sandbox/../foo.db
local-root:   /home/eas/tmp/test/sandbox/
config-db:/home/eas/.fossil
project-code: 430c12926d87d5e8e5517f89d786fbd1a5dde989
checkout: 727acad4494a443864efdf56bef74fbdc3787fef 2015-11-03 19:49:14
UTC
parent:   389a88be2cef9727974da9ecc30d10d3df1bae79 2015-11-03 19:48:58
UTC
tags: trunk
comment:  Add files. (user: eas)
check-ins:3
[little:sandbox] $ lh
total 24K
-rw-r--r-- 1 eas eas 3 Nov  3 17:59 foo.lnk
-rw-r--r-- 1 eas eas 4 Nov  3 17:59 foo
[little:sandbox] $ rm -f foo.lnk
[little:sandbox] $ fossil update
UPDATE foo.lnk
---
updated-to:   727acad4494a443864efdf56bef74fbdc3787fef 2015-11-03 19:49:14
UTC
tags: trunk
comment:  Add files. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
[little:sandbox] $ lh
total 16K
-rw-r--r-- 1 eas eas 4 Nov  3 17:59 foo
lrwxrwxrwx 1 eas eas 3 Nov  3 17:59 foo.lnk -> foo
[little:sandbox] $ cat .fossil-settings/allow-symlinks
on
___
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 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] handling backports

[Warren Young]

On Nov 3, 2015, at 11:48 AM, Eduard  wrote:
> 
> Scenario 1: Suppose a really terrible bug (e.g. an exploitable
> vulnerability) is discovered. Although the latest release is version
> 2.47, it affects every version from 2.12 onwards. Trunk gets quickly
> patched and a new minor version 2.47.1 is released. However, most users
> are still using versions 2.35 and 2.43, and they can't necessarily
> upgrade to 2.47 (e.g. because of some new library dependency that was
> introduced, or some breaking change). What is the correct way of
> handling this in Fossil (or in a DVCS in general)?

Cherrypick the patch, apply it to the 2.35 and 2.43 branches, and release the 
tips of those branches as 2.35.1 and 2.43.1.

Fossil might be able to do most of this work for you via “fossil merge 
--cherrypick”.  Try it.

If it doesn’t, I would just diff the change at the tip of trunk into a file, 
and patch(1) it in by hand on the older feature branches.

If you do not already have feature branches for those past versions, Fossil can 
easily create them on the fly for you.

Let’s say that instead of creating feature branches, you just tagged the 
releases along the trunk instead:

  f up v2.43
  patch -p0 < ~/fix.patch
  f ci --branch v2.43-security -m 'backported fix [867988a67b]'

If you didn’t even tag the releases, then you’d replace “v2.43” in the first 
command with the checkin ID of the last change made before you released 2.43.  
And now you know why tagging releases is a good idea. :)

> Scenario 2: Consider a repository containing a scientific paper's latex
> sources. It is discovered that every single checkin since the very
> beginning has a bug that used to cancel out with another bug in latex
> itself. However that latex bug has been recently patched, and now every
> older version fails to build. The fix itself is just the replacement of
> one line that hasn't changed since the bug was introduced. Again, what
> is the correct way of handling this?

This isn’t a LaTeX issue at all.  I see substantially the same problem with 
#includes on newer versions of GCC.  Older versions of the code carry a 
presumption about the tools used to build the code.  You can’t expect 
10-year-old sources to build correctly under bleeding-edge tools.

Therefore, you either refrain from doing things like checking out older 
versions of the repo on vastly different machines than were current at the time 
those checkins were made, or you create branch points from those old versions 
that are patched to build on current tools.

If you’re asking if Fossil supports a way to retroactively patch all past 
assets checked into the repo so that they build on modern tools, then the 
answer is, “No, on purpose.”  Fossil does not let you edit history, only amend 
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] symlinks (was Re: xkcd on git)

[Warren Young]

On Nov 3, 2015, at 2:51 PM, Joe Mistachkin  wrote:
> 
> Please try the latest Fossil trunk and let us know if that fixes all the
> issues you were seeing.

Version c985d905c6 still fails the test case I posted here yesterday:

  http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg21786.html

Distilled, that post says that if allow-symlinks is enabled, and dereferencing 
a link names a file that is in the Fossil-managed tree, it should behave as if 
you had typed the managed file name instead of the symlink alias to 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

[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

[fossil-users] Suggestions for fossil tickets search page

[Francois Vogel]

Hello,

I would like to submit two suggestions regarding the search page for tickets. 
It may be just a matter of configuring Fossil, I don't know.

To illustrate, I use the Tk fossil repository from the 'Ticket Search' page:
http://core.tcl.tk/tk/ticket

1.
Is it possible to display on this same 'Ticket Search' page the list of 
pre-cooked requests that we currently have access to from the 'Reports' 
(http://core.tcl.tk/tk/reportlist) button?
I would find this much more convenient: on a single page, one box to perform 
textual search in the tickets, and below this the ready-to-be-used SQL requests.

2.
Using the search box in this 'Ticket Search' page, one currently cannot find a 
ticket by its number/hash. E.g.
http://core.tcl.tk/tk/ticket?s=2262711
results in 'No matches for: 2262711' result, whereas ticket 2262711 really 
exists:
http://core.tcl.tk/tk/tktview?name=2262711
Is this a bug of the search engine?

Thanks for your comments.

Regards,
Francois

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

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

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> (1) Default allow-symlinks to true
> (2) Fix bug in which the allow-symlinks setting is not honored while
> opening a repository
>

Please try the latest Fossil trunk and let us know if that fixes all the
issues you were seeing.

--
Joe Mistachkin

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

Re: [fossil-users] xkcd on git

[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 move to a named branch (e.g. 
“git checkout master”) you *lo

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

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 2:44 PM, Joe Mistachkin 
wrote:

>
> Eric Rubin-Smith wrote:
> >
> > (2) Fix bug in which the allow-symlinks setting is not honored while
> > opening a repository
> >
>
> Did the following changes (a while back) not address this?
>
> https://www.fossil-scm.org/fossil/vinfo/010451e7a5fe116a?sbs=0
>
> If not, in what way are they not adequate?


They seem to address the case where the setting is created via
.fossil-settings/allow-symlinks.  Very cool!

But the transcript I pasted uses a "global" setting because of the order in
which I issued the command for that test.  That global setting does not
seem to be honored on open, even in v1.34.

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] meeting tomorrow at 10:00?

[Eduard]

Hi,

I posted to the wrong mailing list. I apologize. Serves me right for
naming them so similarly (and for not getting enough sleep). You may
safely hide/delete/clean up
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg21825.html
(as well as this message) as it was not intended for this list.

Sorry,
Eduard



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

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

[Joe Mistachkin]

Eric Rubin-Smith wrote:
>
> (2) Fix bug in which the allow-symlinks setting is not honored while
> opening a repository
>

Did the following changes (a while back) not address this?

https://www.fossil-scm.org/fossil/vinfo/010451e7a5fe116a?sbs=0

If not, in what way are they not adequate?

--
Joe Mistachkin

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

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

[Eric Rubin-Smith]

>
>
> Just to clarify, what are the behavioral changes needed on the Unix side to
> make
> things work seamlessly?
>

(1) Default allow-symlinks to true
(2) Fix bug in which the allow-symlinks setting is not honored while
opening a repository (requires manual clean-up of symlinks after opening a
repo).  I pasted a transcript session a few emails ago -- let me know if
you would like me to re-paste.  I also submitted a patch to this forum
something like a year ago and then detected a bug with it -- let me know if
you would like me to also re-raise that.


> Are there differing opinions on the changes needed (i.e. and not just
> whether or not there should be any changes in the current behavior)?
>

So far this thread has not reached such a stage, afaik.

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

[Joe Mistachkin]

David Mason wrote:
>
> Exactly.  Please fix symlinks so that if you live only on Unix you get
seamless
> support.  If you work back and forth between Windows and Unix then you
probably
> just don't use symlinks, so it won't be a problem for you! 
>

To All:

Just to clarify, what are the behavioral changes needed on the Unix side to
make
things work seamlessly?

Are there differing opinions on the changes needed (i.e. and not just
whether or
not there should be any changes in the current behavior)?

--
Joe Mistachkin

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

Re: [fossil-users] impersonating users

[Eduard]

On 11/03/2015 06:38 AM, Richard Hipp wrote:
> On 11/3/15, Eduard  wrote:
> 
> The artifact receipt log (/rcvfromlist) shows *all* artifacts that
> have been received.  But it does not filter by artifact type or user -
> it shows everything.
> 
> The list-of-artifacts pages (/bloblist) show all artifacts and
> describes each one.  But it also omits the user and where it was
> received.
That's actually amusing.

> Perhaps you could use those two pages as a guide to devise a new page
> that shows what you want, then send in patches?
I would love to! I doubt I'll have the time over the next month though.
I should probably fill out and send a contributor agreement just in case
I do, though.

Best,
Eduard




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

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

[David Mason]

On 3 November 2015 at 10:48, Eric Rubin-Smith  wrote:

>
> On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal 
> wrote:
>>
>> i can't speak for Richard, but if i had my way, fossil wouldn't support
>> symlinks at all.
>>
>
This would force me to stop using Fossil (or at least updating to a version
that didn't support them), and to recommend to everyone (including the
hundreds of students who I've introduced to Fossil) to be wary using it.

Part of the problem in this discussion is that everyone seems to be
assuming that Fossil is only used for source trees and makefiles.  I
maintain a dozen web sites, a few of them are my course-based ones.  I have
(simplified for expository purposes) let's say 3 repos: Courses, cps710 and
cps506.  Courses has sub-directories Themes (for CSS, etc.) and JScript.
 cps710 and cps506 are nested under Courses, so the structure looks like:
Courses
   Themes
   JScript
   cps710
 Themes -> ../Themes
 JScript -> ../JScript
 f2013
  index.html
  f2013 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 f2015
  index.html
  f2015 -> .
  current -> ../current
  Themes -> ../Themes
  JScript -> ../JScript
 current -> f2015
 index.html -> current/index.html
   cps506
 Themes -> ../Themes
  JScript -> ../JScript
 index.html -> current/index.html
etc.

So symlinks, with nested repos is a huge win for me.  Fortunately, I only
need to set up a new course occasionally, so I only have to fight with
Fossil about symlinks occasionally, but too often!

The poor support for symlinks is far and away my biggest complaint with
Fossil. (The limited support for file permissions is second, because I
often want to put things in the repo that I'm not ready to show the
students yet.)

It's simple: a symlink is a filesystem artifact and should be reflected as
such in the repository.  It should not be followed; if foo is a symlink and
I say "fs add foo/bar" it should probably give an error. (This might
surprise people the first time, but it's easy to explain - foo/bar isn't
part of the repo, regardless of where foo points.)


> :-) Fossil creates a problem by not supporting symlinks properly, and you
> use the volume of complaints about the problem to support your claim that
> the problem was inevitable.
>
> Not implementing them at all, or implementing them poorly as Fossil has,
> is what maximizes complaints -- hence the large amount of emails.
>

Exactly.  Please fix symlinks so that if you live only on Unix you get
seamless support.  If you work back and forth between Windows and Unix then
you probably just don't use symlinks, so it won't be a problem for you!

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

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

[Piotr Orzechowski]

Trying "make distclean" did not help, the error persisted.
#define Tcl_Canceled(a,b) TCL_OK did its job well. :)

Thanks, Joe!

Pozdrawiam / With best regards,
Orzech

W dniu 03.11.2015 o 04:34, Joe Mistachkin pisze:
> Did you try "make distclean" first?
> I wrote both the Tcl and Fossil code in question and I can personally assure
> you that it is safe (also I just tried it myself).  Simply run "./configure"
> with the desired arguments and then add the necessary line to "autoconfig.h"
> before running "make".  You may need to run "make distclean" first if there
> are compiled files from a previous attempt around.
>
> --
> Joe Mistachkin
>




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

[fossil-users] handling backports

[Eduard]

Hi,

I have some questions as to the 'correct' way of handling backports.

Scenario 1: Suppose a really terrible bug (e.g. an exploitable
vulnerability) is discovered. Although the latest release is version
2.47, it affects every version from 2.12 onwards. Trunk gets quickly
patched and a new minor version 2.47.1 is released. However, most users
are still using versions 2.35 and 2.43, and they can't necessarily
upgrade to 2.47 (e.g. because of some new library dependency that was
introduced, or some breaking change). What is the correct way of
handling this in Fossil (or in a DVCS in general)?

Scenario 2: Consider a repository containing a scientific paper's latex
sources. It is discovered that every single checkin since the very
beginning has a bug that used to cancel out with another bug in latex
itself. However that latex bug has been recently patched, and now every
older version fails to build. The fix itself is just the replacement of
one line that hasn't changed since the bug was introduced. Again, what
is the correct way of handling this?

Best,
Eduard



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

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

[Scott Doctor]

why is 10mb a magic number? Why have a magic number at all?


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

On 11/3/2015 5:20 AM, Richard Hipp wrote:

On 11/3/15, Tony Papadimitriou  wrote:

Thanks.

BTW, the help for clean shows this (which is a bit misleading):

--no-prompt  This option disables prompting the user for input and
assumes an answer of 'No' for every question.

But, if prompting is disabled by default, how does that disable it further?


By default it still prompts to confirm deletes of files that cannot be
undone - specifically files larger than 10MB.


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

[fossil-users] meeting tomorrow at 10:00?

[Eduard]

Hi,

Would meeting Wednesday (tomorrow) at 10:00 be okay with you? Please
reply to let me know (unless you've filled in the scheduling poll
 or already told me in person).

Cheers,
Eduard



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

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

[Matt Welland]

On Tue, Nov 3, 2015 at 9:40 AM, Eric Rubin-Smith  wrote:

>
> - Symlinks. Now we're getting into file system specifics. Some users
>> may want to track them because they find them useful. What about users
>> that find FIFOs or block devices or character device useful? Should
>> fossil attempt to save enough information to recreate them?
>>
>
> Support for FIFOs and block devices is a separate discussion.  My defense
> of symlink support does not force me to also defend FIFO and block device
> support.
>

+1

- Extended attributes. Many file systems now have extended attributes.
>> Should Mac users complain because fossil doesn't support HFS+ extended
>> attributes or resource forks?
>>
>
> They may do so if they think it's reasonable, and be subject to all the
> usual considerations around developers' time and attention, etc.  But
> again, for the purposes of arguing whether good symlink support is
> warranted, that is a separate topic.
>

+1


>
> > I think fossil can support the permissions level. Anything further
> > down in the previous list should be part of the project's build cycle.
>
> My biggest complaint about this discussion is that some folks seem to be
> coming at it like fossil is the first tool to confront this issue.  It
> isn't.  There are real examples of programs in the wild (SCMs, no less!)
> that have solved it in ways that are more coherent, more user-friendly, and
> just as easy to implement as what fossil already has.  For Git, our
> poster-child for difficult tools, this is just a total non-issue.
>

+1


> Fossil already sort-of attempts to do what Git does, it just has some bugs
> and incorrect default config values.  So the distance to fixing Fossil is
> quite small.  But closing the gap (and keeping it closed) is much harder
> when a vocal subset of the community argues that supporting symlinks is
> impossible or ill-advised (it is neither, by my lights).
>

I think the Mark Twain quote; “I've lived through some terrible things in
my life, some of which actually happened.” applies here. The objections to
better symlink support are based on imaginings that may or may not ever
eventuate.

There is a simple bottom line that might help. If the developers of fossil
wish to eliminate a large swath of current and potential users then leave
symlink support as is or remove it entirely. Understand that this support
is not really optional for many of us. For me (and I think for others) this
is not a philosophical discussion. This is a pragmatic discussion.


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

[Rich Neswold]

On Tue, Nov 3, 2015 at 10:40 AM, Eric Rubin-Smith  wrote:
> My biggest complaint about this discussion is that some folks seem to be
> coming at it like fossil is the first tool to confront this issue.

I interpret the discussion as a more philosophical one. Should
symlinks be part of a project's contents maintained by an SCM? Or
should symlinks be maintained by makefiles and scripts in the project?

It's been shown fossil's current symlink support is not ideal. It can
be fixed for Unix platforms and can faked enough on other platforms.
Or fossil can take the stance that file system meta-information is
outside the scope of an SCM. And I'd be fine with either decision.
Like, although 'rebase' could be added to fossil, I'm fine with the
fossil philosophy that history is immutable.

> For Git, our poster-child for difficult tools, this is just a total non-issue.

Git was created by Linus, for Linux. Of course it needs to support
Linux-y things.

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

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

[Eric Rubin-Smith]

> - Symlinks. Now we're getting into file system specifics. Some users
> may want to track them because they find them useful. What about users
> that find FIFOs or block devices or character device useful? Should
> fossil attempt to save enough information to recreate them?
>

Support for FIFOs and block devices is a separate discussion.  My defense
of symlink support does not force me to also defend FIFO and block device
support.


> - Extended attributes. Many file systems now have extended attributes.
> Should Mac users complain because fossil doesn't support HFS+ extended
> attributes or resource forks?
>

They may do so if they think it's reasonable, and be subject to all the
usual considerations around developers' time and attention, etc.  But
again, for the purposes of arguing whether good symlink support is
warranted, that is a separate topic.

> I think fossil can support the permissions level. Anything further
> down in the previous list should be part of the project's build cycle.

My biggest complaint about this discussion is that some folks seem to be
coming at it like fossil is the first tool to confront this issue.  It
isn't.  There are real examples of programs in the wild (SCMs, no less!)
that have solved it in ways that are more coherent, more user-friendly, and
just as easy to implement as what fossil already has.  For Git, our
poster-child for difficult tools, this is just a total non-issue.

Fossil already sort-of attempts to do what Git does, it just has some bugs
and incorrect default config values.  So the distance to fixing Fossil is
quite small.  But closing the gap (and keeping it closed) is much harder
when a vocal subset of the community argues that supporting symlinks is
impossible or ill-advised (it is neither, by my lights).

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

[Eric Rubin-Smith]

On Tue, Nov 3, 2015 at 1:33 AM, Stephan Beal  wrote:

>
> On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith 
> wrote:
>
>> the user when trying to move a tarball from one OS to another.  In other
>> words, I believe that you perceive a dichotomy that is false (between (a)
>> not implementing symlinks at all and (b) implementing them while having
>> fossil perfectly and automatically solve all complications that may arise).
>>
>
> That sounds like a fair summary of my feelings on SCM support for
> symlinks, but i'd argue that if a system (SCM) cannot do (b) for the vast
> majority of use cases, then it probably shouldn't be implemented at all.
> Why not? Because it's the _displeased_ users who complain the loudest when
> something doesn't work how they want/expect it do, and that percentage of
> users is relatively high in the case of symlinks.
>
> A user who only ever uses fossil on unix should get unix symlink semantics
>> on unix, without quirks or surprises.  Surely you and DRH would agree with
>> that?
>>
>
> i can't speak for Richard, but if i had my way, fossil wouldn't support
> symlinks at all. They are inherently platform-dependent and, IMHO, belong
> in the build process, not the SCM. They are a big can of worms, as we can
> see by large amount of emails on the topic. To be clear: i use symlinks all
> over the place on my systems, i just refuse to use them in an SCM. Call me
> old fashioned.
>
>

:-) Fossil creates a problem by not supporting symlinks properly, and you
use the volume of complaints about the problem to support your claim that
the problem was inevitable.

Not implementing them at all, or implementing them poorly as Fossil has, is
what maximizes complaints -- hence the large amount of emails.  I wouldn't
dream of complaining about Git's support of symlinks, because it just works.

I just don't think this is a deep conundrum.  Lots of cross-platform
programs have to deal with symlinks, have done so, and the universe has not
collapsed from the logical implications.  If the link is broken just fix
it.  If the OS doesn't support symlinks then those see some reasonable
degradation, possibly coupled with warnings.  And those of us who use OSes
with symlink support don't have to suffer needlessly because of the poor
decision-making of other OS authors.


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

Here you give away the game by saying "IMO".  Whether it's wrong is a
question of policy, as you seem to admit.  And such examples have clearly
led you down a path of arguing that your policy is the right one -- to the
detriment of the tool.

Your particular example is actually great for my case, because it applies
with equal force to the case of filesystems.  A filesystem can be mounted
at any mount point, so an absolute symlink to '/etc' that works fine when
the FS is mounted at '/' will not be correct when the FS is mounted at
'/foo/bar'.  So absolute symlinks are also wrong in this case.  Why should
Linux assist in doing the wrong thing?

Well, because it's a really useful tool.  Sometimes the tool can be misused
or uncover some corner cases or whatever, but overall it's really useful.
So let's support it and let the user deal with those weird cases if they
come up (or just wallow in the pure bliss of a useful tool if the cases
don't come up).


> Stated yet another way: we don't expect the SCM to solve all problems that
>> users create.
>>
>
> But if it sets out to solve them, then it should solve them, not provide a
> half-solution to philosophically unsolvable problems. (IMO.)
>

Your argument is analogous to an argument that compilers can't detect and
correct all program bugs, so we may as well not write compilers at all.
This is an enormous problem, you could argue, because almost all programs
have bugs, and so the compiler is doomed to fail almost every time!

Of course you wouldn't say that, because you would rightly notice that this
is a false dichotomy: it's not the compiler's job to detect all program
bugs.

We can support symlinks without setting out to solve all problems that
arise.  It's not a half-solution -- it's a full solution to a narrower
(and, in fact, pretty simple) problem.


>
> For context, my particular use case: we need the openssl source tree in
>> our project, and that tree contains internal symlinks.  Again, people have
>> to jump through silly hoops to get new repos set up properly, because
>> fossil breaks those symlinks by populating new repos with flat text files
>> (and this goes undiscovered til the openssl build fails in mysterious
>> ways).
>>
>
> To the best of my knowledge, if symlinks are enabled in the fossil config,
> it will DTRT with them (to the best of its ability). i haven't tried it,
> but that's my understanding of the feature. IIRC symlinks are on by default
> on Unix 

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

[Rich Neswold]

On Tue, Nov 3, 2015 at 12:33 AM, Stephan Beal  wrote:
> On Mon, Nov 2, 2015 at 6:32 PM, Eric Rubin-Smith  wrote:
>> A user who only ever uses fossil on unix should get unix symlink semantics
>> on unix, without quirks or surprises.  Surely you and DRH would agree with
>> that?
>
> i can't speak for Richard, but if i had my way, fossil wouldn't support
> symlinks at all. They are inherently platform-dependent and, IMHO, belong in
> the build process, not the SCM. They are a big can of worms, as we can see
> by large amount of emails on the topic. To be clear: i use symlinks all over
> the place on my systems, i just refuse to use them in an SCM. Call me old
> fashioned.

When this discussion started (many messages ago), I shared Mr
Rubin-Smith's opinion. but as arguments were presented, I'm now
leaning towards Mr. Beal's. We're arguing how much file system
semantics should 'fossil' manage? The more you manage, the tougher it
gets to be cross-platform.

How much of the spectrum should fossil track:

- Files. This is a no-brainer; the whole purpose is to track changing
file contents.
- Directories. Also a no-brainer; all serious file systems have a way
to organize files into directory trees (although I guess this means
fossil won't run on CPM machines) and directories are a very useful
way to organize a project's files.
- Permissions. As a fossil user, I haven't been tripped up by
incorrect permissions, so I don't know if it saves Unix permissions or
not. Whatever it's doing, it seems correct in a Unix-like environment.
- Symlinks. Now we're getting into file system specifics. Some users
may want to track them because they find them useful. What about users
that find FIFOs or block devices or character device useful? Should
fossil attempt to save enough information to recreate them?
- Extended attributes. Many file systems now have extended attributes.
Should Mac users complain because fossil doesn't support HFS+ extended
attributes or resource forks?

I think fossil can support the permissions level. Anything further
down in the previous list should be part of the project's build cycle.

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

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

[Richard Hipp]

On 11/3/15, Tony Papadimitriou  wrote:
> Thanks.
>
> BTW, the help for clean shows this (which is a bit misleading):
>
> --no-prompt  This option disables prompting the user for input and
> assumes an answer of 'No' for every question.
>
> But, if prompting is disabled by default, how does that disable it further?
>

By default it still prompts to confirm deletes of files that cannot be
undone - specifically files larger than 10MB.
-- 
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

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

[Tony Papadimitriou]

Thanks.

BTW, the help for clean shows this (which is a bit misleading):

--no-prompt  This option disables prompting the user for input and 
assumes an answer of 'No' for every question.


But, if prompting is disabled by default, how does that disable it further?

-Original Message- 
From: Richard Hipp

Sent: Tuesday, November 03, 2015 3:09 AM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] fossil v1.34 unexpected CLEAN command 
changesfrom v1.33


On 11/2/15, to...@acm.org  wrote:
I built the latest version and (unfortunately, for me) CLEAN no longer 
asks

for confirmation.

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


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



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

I can undo the specific one I want to keep?

Thanks.




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


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

Re: [fossil-users] xkcd on git

[Michal Suchanek]

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

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

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

So yes, there is some issue here.

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

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

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

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

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

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

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

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

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

Thanks

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

Re: [fossil-users] impersonating users

[Richard Hipp]

On 11/3/15, Eduard  wrote:
> Hi,
>
> It seems that anyone with checkin privileges can push anything to a
> fossil server, including artifacts that claim to come from other users.
> I understand why this is (I'm not complaining); I just want to know
> whether there's some command/page for listing recently received control
> artifacts whose user does not match the user pushing them, so they can
> be further inspected.
>

The artifact receipt log (/rcvfromlist) shows *all* artifacts that
have been received.  But it does not filter by artifact type or user -
it shows everything.

The list-of-artifacts pages (/bloblist) show all artifacts and
describes each one.  But it also omits the user and where it was
received.

Perhaps you could use those two pages as a guide to devise a new page
that shows what you want, then send in patches?
-- 
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