Re: [fossil-users] Git just got shallow and sparse clones

[Steve Stefanovich]

Just‎ to contribute my 2 cents to this discussion, for our workflow I'd find 
sparse clones much more useful than shallow ones, although I can see how deep 
history can slow initial clone, and that past certain point is rarely useful.

It's not our problem - but we have thousands of separate source files in 
modules that are directory subtrees. Yes, we split those in different Fossil 
repos, but this approach introduces dependencies and repo management overheads. 
It's easier to have a single encompassing repo than 30 separate ones, 
especially if documentation and tickets are involved. 
‎
There is also IP protection aspect. Being able to clone a certain directory 
only from the source tree would allow us to restrict the third party developers 
to see just what they are supposed to see and are allowed to work on. From that 
perspective sparse clones would have to be 'special' in a sense that you can't 
sync fully on demand afterwards. This probably means special privilege with 
list of directory globs an user is allowed to clone sparsely. 
‎
I am not quite sure how would it all work in Fossil though. The sparse clone 
from a dir would have to fetch all the check-ins that contain changes to 
affected files, but drop the other artifacts outside the dir. I suppose we 
could have missing artifact warnings on update/status/diff (similar to current 
missing common ancestor warnings in certain merge scenarios), but it will be 
nice if Fossil is aware that repo is a special sparsely cloned one, and 
interpret those missing artifacts by showing (or hiding, if preferred) 
appropriate warnings to avoid confusion. 

Finally, there is a question of wikis and tickets. Following this model sparse 
clone would not fetch them, but perhaps it is more useful if this is governed 
by existing user wiki/ticket privileges. 
‎
S. ‎


  Original Message  
From: Warren Young
Sent: Tuesday, 7 February 2017 10:58
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Git just got shallow and sparse clones

On Feb 6, 2017, at 4:49 PM, Warren Young  wrote:
> 
>> allow cloning a repository “shallowly"
> 
> That’s not what I mean by “shallow,” since according to the docs,[1]

Oh, I see the --no-single-branch bit now. Sigh, another confusing Git default.

Even so, it still doesn’t quite do what I want:

- I want to give --depth in days, not checkins.

- I want to allow the cloned-from repository to set a sensible default, so that 
very large repos can require that cloners specify something like --deep to get 
everything.

Personally, I don’t need this for my own repositories. I’m just putting out 
ideas to handle extremely large repos.

As for my second point above, I’d have been happy if the Linux kernel source 
repo I checked out onto a Raspberry Pi had only given me the past 30 days or 
so, without me having to know about --depth. I only wanted --depth=1 anyway.
___
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] unable to revert fossil mv

[Steve Stefanovich]

This is an excellent example of a confusing mv command and a bad default 
choice, as encountered by someone presumably new to Fossil.

The problem is that Fossil doesn't move files on its own, by default. Why would 
anyone want that behaviour, especially as a default, is beyond me.

You need to specify --hard and to have an executable that has been compiled 
with such an option. Search for Joe Mistachin's response to my question about 
it on the mailing list for details.


Cheers,
Steve‎
  Original Message
From: arnoldemu
Sent: Saturday, 29 October 2016 23:45
To: fossil-users@lists.fossil-scm.org
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] unable to revert fossil mv


Update:

I am seeing this:

kevin@kevin:~/arnold/test/disc$ fossil changes
MISSING disk_sizes/data.dsk
MISSING disk_sizes/data2sides.dsk
MISSING disk_sizes/ramdosd1.dsk
MISSING disk_sizes/system.dsk
MISSING disk_sizes/system42.dsk
MISSING disk_sizes/system80t1s.dsk
MISSING disk_sizes/test.dsk
MISSING disk_sizes/vortex.dsk


if I do touch to make these missing files and then do a revert.

Fossil shows me

kevin@kevin:~/arnold/test/disc/disk_sizes$ fossil revert
DELETE test/disc/disk_sizes/data.dsk
DELETE test/disc/disk_sizes/data2sides.dsk
DELETE test/disc/disk_sizes/ramdosd1.dsk
DELETE test/disc/disk_sizes/system.dsk
DELETE test/disc/disk_sizes/system42.dsk
DELETE test/disc/disk_sizes/system80t1s.dsk
DELETE test/disc/disk_sizes/test.dsk
DELETE test/disc/disk_sizes/vortex.dsk
REVERT test/disk_sizes/data.dsk
REVERT test/disk_sizes/data2sides.dsk
REVERT test/disk_sizes/ramdosd1.dsk
REVERT test/disk_sizes/system.dsk
REVERT test/disk_sizes/system42.dsk
REVERT test/disk_sizes/system80t1s.dsk
REVERT test/disk_sizes/test.dsk
REVERT test/disk_sizes/vortex.dsk
"fossil undo" is available to undo changes to the working checkout.

and then:

kevin@kevin:~/arnold/test/disc/disk_sizes$ fossil changes
kevin@kevin:~/arnold/test/disc/disk_sizes$ cd ..

i try again:

kevin@kevin:~/arnold/test$ fossil mv disk_sizes disc/disk_sizes
RENAME test/disk_sizes/data.dsk test/disc/disk_sizes/data.dsk
RENAME test/disk_sizes/data2sides.dsk test/disc/disk_sizes/data2sides.dsk
RENAME test/disk_sizes/ramdosd1.dsk test/disc/disk_sizes/ramdosd1.dsk
RENAME test/disk_sizes/system.dsk test/disc/disk_sizes/system.dsk
RENAME test/disk_sizes/system42.dsk test/disc/disk_sizes/system42.dsk
RENAME test/disk_sizes/system80t1s.dsk test/disc/disk_sizes/system80t1s.dsk
RENAME test/disk_sizes/test.dsk test/disc/disk_sizes/test.dsk
RENAME test/disk_sizes/vortex.dsk test/disc/disk_sizes/vortex.dsk

kevin@kevin:~/arnold/test$ fossil changes
MISSING disc/disk_sizes/data.dsk
MISSING disc/disk_sizes/data2sides.dsk
MISSING disc/disk_sizes/ramdosd1.dsk
MISSING disc/disk_sizes/system.dsk
MISSING disc/disk_sizes/system42.dsk
MISSING disc/disk_sizes/system80t1s.dsk
MISSING disc/disk_sizes/test.dsk
MISSING disc/disk_sizes/vortex.dsk

:(

No way to recover :(



___
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] basic usage question - empty directories

[Steve Stefanovich]

At the end, you didn't add the empty-dirs file. You need to do 'fossil add * 
--dotfiles' or explicitly do 'f add .fossil-settings/empty-dirs', then commit. 
Then a subsequent checkout will create the directories.

S.

  Original Message
From: Adam Jensen
Sent: Tuesday, 2 August 2016 10:02
To: fossil-users@lists.fossil-scm.org
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] basic usage question - empty directories


On 08/01/2016 07:25 PM, Steve Stefanovich wrote:
>
> ‎Create a .fossil-settings directory in the root of your checkout, and in it 
> add empty-dirs file with relative paths to where you want empty directories 
> created, fossil add/commit.
>

Is there documentation for that approach? I can't seem to get it to
work. Could you provide an example demonstrating the method, or review
my attempt (below) and provide corrections?

mkdir test
cd test/
mkdir repo
mkdir project
cd repo
fossil init test.fossil
cd ../project/
fossil open ../repo/test.fossil
touch README
mkdir empty1
mkdir notempty1
touch notempty1/foo.tcl
tree
.
|-- empty1
|-- notempty1
|   `-- foo.tcl
`-- README

mkdir .fossil-settings
vi .fossil-settings/empty-dirs
cat .fossil-settings/empty-dirs
./empty1

fossil add *
ADDED  README
ADDED  notempty1/foo.tcl

fossil commit -m "Initial checkin"
New_Version: 977b2342d05cd9b04fb6a1963fcbb7a96823fe75
___
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] basic usage question - empty directories

[Steve Stefanovich]

‎Create a .fossil-settings directory in the root of your checkout, and in it 
add empty-dirs file with relative paths to where you want empty directories 
created, fossil add/commit.

Cheers,
Steve
---

From: Adam Jensen
Sent: Tuesday, 2 August 2016 09:19
To: fossil-users@lists.fossil-scm.org
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] basic usage question - empty directories


Hi,

I haven't before used fossil to manage a project. Is there a way to
commit empty directories to the repository so the project's directory
structure can be preserved and reconstructed?

Actually, some of the directories aren't empty but rather their contents
are ignored:

fsl add --ignore '*.db,*.fossil,*.log,*.mp3' *
fsl commit -m "Initial checkin"

Is this something simple that I haven't yet discovered in the
documentation or am I doing something terribly wrong?

Thanks!
___
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] Purging data from Fossil

[Steve Stefanovich]

> (A)  Suggest a better name than "fossil trim"

How about existing "fossil bundle export"? See (C) discussion below. Having 
bundles, trim and shun is more confusing for newcomers than single bundle 
export (or equivalent new command).

(B)  Define the syntax of ARGS.

This needs some use case discussion first, but I think existing bundle export 
args will be a good start. What needs to be added is file or directory options.

(C)  Define a safety mechanism that allows content to be restored if
it is accidentally trimmed when there are no other repos available
with which to sink.  Perhaps the trimmed content gets written into a
separate "trash-can" database?

This will be solved by extending bundles functionality. You effectively create 
a trimmed repo with 'fossil bundle export --standalone' (I realise standalone 
is supposed to mean something else in current bundle world, but it currently 
doesn't work anyway). In this context it will create a standalone repo that can 
be opened and worked on its own. 

Regarding use cases,  I think there are 2 orthogonal ‎categories of use which 
may intersect or combine:

1. Strip out files and directories, i.e. get rid of all artifacts that don't 
relate to this files (or export only those that touch these files).  Obviously 
for sensitive or proprietary information, but this can be useful  for repo 
'sharding' where only a subdirectory tree can be exported for someone to 
develop on, or to manage third party libraries. 

So we'd need a file glob in args here, maybe even as a file checked in 
.fossil_options like empty-dirs for lots of trimming, and so it can be set for 
synching once we get to that. It would be nice if glob worked from both include 
or exclude perspective (export only these files, or export all files except 
these). 

2. Strip out history of work, i.e. --from --to tags, --branch. For performance 
reasons on large repos, as it is unlikely that anything older than xxx years or 
months is required for active development. Or perhaps to submit drive-by 
patches or features, which bundle currently covers. Or rudimentary permissions 
management, where some devs are not to see somebody else's sensitive work in 
another branch, but others should. 

Args here would need to be recognised as hashes, tags or dates. 

I would also think that this kind of export should ensure that if a subset of 
artifacts or commits is exported, all the files touched must check out. Perhaps 
an initial checkin that adds the missing file, is tagged in a special way and 
never syncs anywhere. A special case of 'fossil rebase' :) The alternative is 
that the file simply doesn't check out with a warning, which is the current 
bundle export functionality and is not that useful. 

I am much more interested in 1. Don't care that much about 2. - but I can use 
branch export where all the files touched are guaranteed to check out, for 
subcontracting type work. 

I think if this functionality or some subset of it does get implemented, it 
would make Fossil much more malleable for users coming from Git world and make 
big differences between the two (sharding vs replication, rewriting history) 
matter less. 

Cheers,
Steve
___
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] Further mailing list configuration changes.

[Steve Stefanovich]

Works, don't touch it anymore :)

Cheers,
Steve
---
‎
  Original Message
From: Richard Hipp
Sent: Monday, 27 June 2016 14:13
To: fossil-users
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] Further mailing list configuration changes.


The "From:" removal has been turned off and in its place "Reply-To:"
removal has been turned on.  This is a test message to verify the new
configuration.  Further changes might occur depending on how this one
goes.

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

[fossil-users] Windows 1.35 binary does not know about mv-rm-files setting

[Steve Stefanovich]

It looks like it has not been compiled with the correct flag. Can this be 
amended and correct version posted?‎ It is confusing. Summarised here:

‎https://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20823.html

Cheers,
Steve
___
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] No progress on "fossil cp"

[Steve Stefanovich]

>> Not that this is much consolation to you, Warren, or anyone else that ever 
>> had to deal with this, but the merge issue will be fixed in the next release 
>> (or now if you compile your own Fossil binary):

> Thank you, drh!

And thanks to Joel for taking on this long-lasting and annoying bug and 
providing the fix.

This will also improve Fossil reputation when comparing with other VCSes. I've 
seen it used - rightly so, because it is an essential feature for code 
refactoring - as an argument against Fossil on discussions at HN, Reddit and 
elsewhere. 

Cheers,
Steve
___
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] repo sharding (was: libfossil scripting mini-demo)

[Steve Stefanovich]

> I’d hoped bundles could do this, but even
> with --standalone, you don’t get a repo that 
> can stand on its own.

This looks like a bug to me. I tried to use --standalone, --from and --to but 
none of those options work. Only --branch works. 

(I am using bundles to graft trunk from one repo to another.)

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

Re: [fossil-users] How to get artifact's content as raw text in one click?

[Steve Stefanovich]

I think it is a good idea.‎ It would be especially useful for search results - 
see:

http://lists.fossil-scm.org:8080/pipermail/fossil-users/2015-March/020624.html

‎--
S.

No guess at all. Why? [Raw] button will force appending '=text' to
'Download' URL. Click on [Raw] is mean "you know what you want". If that
is bad idea, sorry for the noise.

Sergei‎
___
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] Versions & manifests

[Steve Stefanovich]

> > Would it be too difficult to put the branch tag (i.e the tag with asterisk 
> > from
> 'fossil br li' output) in the first line of manifest.tags?
> 
>It probably wouldn't, but I've been trying to keep the code agnostic with
> regards to being used in a checkout or not.  The "current branch tag" is not
> applicable when generating archives from the web ui, for instance. 

I didn't mean the current checkout branch tag, just used that as
an example. I meant branch tag of the check-in you're getting the
source from, i.e. what's in the manifest.uuid.

>Is this not sufficient for your needs?  I'm not completely opposed to
> implementing what you're asking for, but if it can already be done without
> adding a "within a checkout" special case, I would prefer to leave it as it 
> is.

I don't think you need such a special case. Maybe a better way is to extract
raw tags, or provide an option to do so, because then the branch tag is easily
distinguished:

C:\Temp>f timeline -t ci -R t.fossil
=== 2016-01-05 ===
08:02:44 [11a34d67d0] Branch 
(user: Steve tags: test_branch, branch_tag)
=== 2015-12-27 ===
02:45:54 [0a1fb00ed9] initial empty check-in 
(user: Steve tags: trunk, trunk_tag)
+++ no more data (2) +++

C:\Temp>f tag list --raw trunk -R t.fossil
branch=trunk
sym-trunk
sym-trunk_tag

C:\Temp>f tag list --raw test_branch -R t.fossil
branch=test_branch
sym-branch_tag
sym-test_branch
sym-trunk

Cheers,
Steve
___
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] Versions & manifests

[Steve Stefanovich]

Would it be too difficult to put the branch tag (i.e the tag with asterisk from 
'fossil br li' output) in the first line of manifest.tags?

We use the combination of uuid and branch tag for versioning. 

S. 

  Original Message  
From: Jan Danielsson
Sent: Monday, 4 January 2016 16:03‎
Subject: Re: [fossil-users] Versions & manifests‎



___
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] Show current checkout and branch in Web UI

[Steve Stefanovich]

Thanks, Richard!

Since it seems you have some bandwidth available to play with Fossil, could you 
have a look‎ at those two rename bugs that cause grief too, in case these are 
quick fixes? The second one is more important.

1. (In May) Anofos reported that renaming a file on the branch and adding it 
back later results in lost file when merged back to trunk. Git does the right 
thing.

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20417.html

2. ‎(In June) Andy G reported after renaming file in a branch, merging trunk 
changes to it works only once, and subsequent merges do nothing:

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


  Original Message
‎
From: Richard Hipp
Sent: Tuesday, 29 December 2015 04:51
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Show current checkout and branch in Web UI


On 12/27/15, Richard Hipp  wrote:
> My previous patch was not quite right.  After a second look, I checked
> in a slightly different fix.  I won't be able to test the new fix on
> windows until about this time tomorrow.
>

I can now confirm that the patch checked in yesterday fixes the
problem on Windows 7, which presumably means it is also fixed on Win8
and Win10.
--
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] Show current checkout and branch in Web UI

[Steve Stefanovich]

> >> It only works if you start it without a repository name from within
> >> an open checkout.
> >
> > But I do start it from the open checkout directory without arguments,
> > and it doesn't work ('no such object: current'); tried 1.33 and 1.34, on
> Windows.
> 
> Works for me on Linux.  I'll fire up a windows box and try it there after I 
> finish
> the other email I was working on

It definitely doesn't work on Windows. I've tried previously at work with 
Windows 7,  and again at home with windows 8.1:

f new test.fossil
f open test.fossil
f server -> localhost:8080/info/current => ' No such object: current'
Ctrl-C
f ui -> localhost:8080/info/current => shows the initial checkout

Cheers,
Steve
___
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] Show current checkout and branch in Web UI

[Steve Stefanovich]

> It only works if you start it without a repository name from within an open 
> checkout.

But I do start it from the open checkout directory without arguments, and it 
doesn't work ('no such object: current'); tried 1.33 and 1.34, on Windows. 
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Show current checkout and branch in Web UI

[Steve Stefanovich]

Is there a way‎, if Fossil is running as 'fossil ui'‎ from checkout directory, 
to show which hash and branch the checkout (along with other info, like commit 
timestamp, user and comments) is currently at?

We have multiple checkout builds for different environments, and I would like 
to show this info in a web page (possibly as embedded doco within Fossil), but 
I'd rather it updates automatically than someone having to maintain it.

I'm aware I can enable manifest.uuid and get the current hash from there, or 
use TH1 checkout command to get a directory path, but I don't know how to get 
the rest of the info (branch, user, timestamp, comments) within Fossil embedded 
markdown file.

If this can be done, how?

Cheers,
Steve


___
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] Show current checkout and branch in Web UI

[Steve Stefanovich]

Yes, this is helpful - if served by 'fossil ui' it shows the current checkout 
timeline and info that I need. 
‎
However, I realised if  this is to be visible to all the team, I need to use 
'fossil server'. 

In that case, Fossil doesn't know what current means (i.e. /info/current 
returns 'No such object: current' and /timeline?c=current just shows 11 latest 
checkins). 

S. ‎‎
‎
  Original Message  
From: Richard Hipp
Sent: Wednesday, 23 December 2015 15:00
‎

Do the following URLs provide what you need?

http://localhost:8080/timeline?c=current
http://localhost:8080/info/current

___
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] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned on HN

[Steve Stefanovich]

This ‎reads better then previous version and more detail is given, thanks.
‎
The ve‎ry last bit (4.2 - Fossil inability to push/pull single branch) sounds 
somewhat weak, though. 
‎
Perhaps it could be strengthened by mentioning bundle command as a way to 
export a branch, but I also think bundle command should be extended to make it 
truly useful for scenarios like these. 

What needs to be additionally done is:

1. Ensure --standalone option extracts the full artifact, not just the last 
delta which will make a bundle, well, a standalone repo  - unless I'm wrong 
what standalone is supposed to mean. 

2. (Optional) Extend the bundle export command ‎so 
‎a new repo can be created with export contents automatically imported into it. 
For example, this way people can export a single check-in as the root before 
adding further bundles to it.  This is useful because cross-merges between 
repos could be done this way with --force option.
‎
Richard, what do you think? 

Cheers,
Steve‎

---
‎
  Original Message  
From: Richard Hipp
Sent: Thursday, 17 December 2015 03:16
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] Rewrite of fossil-v-git.wiki. Was: Fossil mentioned 
on HN

Based on comments on HN and on this mailing list, I have attempted to
rewrite the fossil-v-git.wiki document
(https://www.fossil-scm.org/fossil/doc/trunk/www/fossil-v-git.wiki) to
better summarize the differences between the two products.

Your feedback on the rewrite, and especially suggestions for improving
it, are welcomed.

-- 
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] BUNDLE problems/questions - resent to the correct list this time :)

[Steve Stefanovich]

‎I don't think bundle --standalone option works. See my case here:

‎http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg21596.html

S.

From: to...@acm.org
Sent: Tuesday, 8 December 2015 20:11
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] BUNDLE problems/questions - resent to the correct list 
this time :)


1. I’m trying to create a new repo by taking a branch from an existing one.  
So, I thought the easier way would be the new ‘bundle’ feature.

I tried this batch file (Win7):
-
f new xxx.fossil --date-override 2014-01-01
f o xxx.fossil
f bun export xxx --standalone --branch %1 –R original.fossil
f bun import xxx --publish --force
-

where %1 is replaced by the name of the branch I want to extract.  The 
--date-override is only there to place the initial empty commit before the 
imported content.  But, it makes no difference if I use it or not.

The problem: For some branch trying to “FOSSIL UPDATE branch” (from the initial 
empty trunk) works fine, and all the files are checked out.

Doing the exact same thing for a different branch, however, gives me:
content missing for ... each file ...
missing content, unable to update

If I use the UI I can see the file contents just fine.  So, the files are there 
but, for whatever reason, inaccessible.

What can be the cause of this?  Why does the above sequence of commands work 
for one branch but not another (from the same repo)?

2. Can I make the imported bundle end up in trunk without manually shunning the 
initial empty commit, and making the first node of the imported bundle branch 
the beginning of a new branch named ‘trunk’?

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

Re: [fossil-users] Fossil internal error: out of memory

[Steve Stefanovich]

>> From: fossil-users-boun...@lists.fossil-scm.org 
>> [mailto:fossil-users-boun...@lists.fossil-scm.org] 
>> On Behalf Of Stephan Beal
>> i would be interested in hearing from any other users who store 
>> huge files in their repos, and how much memory fossil eats while doing so.

I remember fiddling with a binary file once that made Fossil 32-bit error out 
on commit. 64-bit worked fine on 8Gb RAM, Windows.

I don't remember what the file size was. I could look it up, but I believe this 
is unrelated to Alexey's problem (i.e. problems with deltas of large non-binary 
files).

S.

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

[fossil-users] Search on file name, display history?

[Steve Stefanovich]

‎Can the search be extended to search on file names as well, and results to 
include the link to jump straight away to file history?

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

Re: [fossil-users] Search on file name, display history?

[Steve Stefanovich]

‎Search actually works very well over all committed files (we run it with '*'‎ 
and set to trunk on the server, with an index).

I find it a valuable feature, because our module structure has lots of files 
and a class can live in multiple files named the same, but in different 
directories.

I usually  search for the content and then a) copy the link to Emacs 
minibuffer, adjust it a bit and open the checked-out file, or b) copy to the 
browser address bar and adjust it to get to the Fossil finfo timeline for 
specific file.

So if Fossil can allow a search for filename, give‎ me a relative link to the 
file for use case a) and finfo history link for b) - that would be just awesome.

I've discussed this and other things before, and would be keen to hear other 
people thoughts:


http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg19535.html

(Point 3. is fixed, BTW.)

P.S. Even when rebuilding index over a specific branch and repeating a) or b) 
above, it takes just a couple of seconds for hundreds of files and it's heaps 
faster then traversing the files via Fossil files menu.


‎
From: sky5w...@gmail.com



Maybe a dumb question, but can search be expanded to repo files? Maybe just the 
tip? Is it a speed issue or too many results to process?

On Tue, Nov 10, 2015 at 9:32 PM, jungle Boogie 
<jungleboog...@gmail.com<mailto:jungleboog...@gmail.com>> wrote:

Sent from my iPhone 7.1
On Nov 10, 2015 5:04 PM, "Steve Stefanovich" 
<s...@stef.rs<mailto:s...@stef.rs>> wrote:
>
> ‎Can the search be extended to search on file names as well, and results to 
> include the link to jump straight away to file history?
>

I support this. Sometimes the file name is known but it's location is unknown. 
Instead of spending time expanding all directories,

> S.
>
>
>

___
fossil-users mailing list
fossil-users@lists.fossil-scm.org<mailto: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] MERGE problem (with renames/deletes)

[Steve Stefanovich]

>>‎ Yes, we discussed this one the list before. The fossil should at
>> least warn about it, or more accurately raise a conflict, because
>> that's what it really is. It's a bug.

> I can see a desire to raise a merge conflict, but I don't think it
> is a bug. Isn't it reasonable to say "removing the file from a
> branch means the file is no longer tracked in the branch, and thus
> no actions should be taken on an untracked file"?

It is reasonable, if the removal happened *at the branch*. But
it is being brought by merge from elsewhere, say trunk. In that
context, it is confusing.

Additionally, what frequently happens next is that the file gets
re-added on the branch to keep going, and when the finished code gets
merged back to the trunk, "no common ancestor" warnings just keep on
surprising.

From design point of view, I think Fossil should not be implying that
delete is any more special than the update. Treating both the same and
raising conflicts, in the same fashion as currently happens with
updates, would give the opportunity to user to decide what to do.

> By extension, if you have a working copy, you remove a file (stop
> tracking the file), then make some changes to the file, do you
> expect fossil to warn you there are changes to a no longer tracked
> file?

No, of course not. But this is about deletions happening elsewhere and
being brought in by merge. I think a more appropriate example is the
one I provided above.

> What does git do in this case?

You mean how it handles merge of deleted files? I honestly don't know,
I'm not using Git.

>> Since we've got Richard's attention to this thread, I'd point him
>> to related bugs that were reported‎ before. Maybe these should be
>> entered as tickets so we don't lose track of them.
>>
>>‎ 1. (In May) Anofos reported that renaming a file on the branch and
>> adding it back later results in lost file when merged back to
>> trunk. Git does the right thing.
>>
>> http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20417.html
>> 
>>2. ‎(In June) Andy G reported after renaming file in a branch,
>> merging trunk changes to it works only once, and subsequent merges
>> do nothing:
>> 
>> http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20758.html‎

> I'm not sure what to do with renaming.

I don't know how Fossil deals with merging renames internally, but
these are bugs, clearly. I have noted them again in case they may be
related to current implementation of merging deletes.
___
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] MERGE problem (with renames/deletes)

[Steve Stefanovich]

‎Yes, we discussed this one the list before. The fossil should at least warn 
about it, or more accurately raise a conflict, because that's what it really 
is. It's a bug.

Since we've got Richard's attention to this thread, I'd point him to related 
bugs that were reported‎ before. Maybe these should be entered as tickets so we 
don't lose track of them.

‎1. (In May) Anofos reported that renaming a file on the branch and adding it 
back later results in lost file when merged back to trunk. Git does the right 
thing.


http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg20417.html



2. ‎(In June) Andy G reported after renaming file in a branch, merging trunk 
changes to it works only once, and subsequent merges do nothing:



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


From: Scott Robison
Sent: Friday, 25 September 2015 02:51
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] MERGE problem


Is there a chance that these are files you previously deleted from a branch? 
For example:

1. Create branch from trunk.

2. Deleted files from branch and committed.

3. Made changes to files on trunk and committed.

4. Merged from trunk expecting the changed files to come into branch.

There are some scenarios where what you describe can legitimately happen, but 
in order to troubleshoot it one would have to look at the entire state of the 
repository to see what merge is (or is not, as the case may be) doing.

On Thu, Sep 24, 2015 at 8:59 AM, Tony Papadimitriou 
> wrote:
I’m in some branch and doing a MERGE from trunk.

Everything OK except for some newly added files on trunk that were not in the 
current branch, but a merge was expected to deal with them also.
But, they do not ‘copy over’.  The result is the project is incomplete as the 
updated files depend (#include) the missing ones.

I can do a manual UPDATE to bring each file in the working branch from trunk 
‘by hand’ but shouldn’t a MERGE take care of that also?

Thanks.

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




--
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] Cloning repos in local group?

[Steve Stefanovich]

‎Thanks for this. It worked after I reset each user password via web interface. 
Just doing ' f config sync user' won't work for cloning.
‎
  Original Message  
From: Andy Bradford
Sent: Saturday, 19 September 2015 04:11
‎...
No, you don't have to duplicate user management. When you are managing
users through the web, there is an option to save changes to new users
to the Group or just to the single repository.

___
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] Best way to work with two related repos?

[Steve Stefanovich]

‎I've managed to do this by using bundles.  Like OP, I needed to be able to 
share work between repos in seamless way. See below for my use case. 

The only drawback is that I had to share more than I wanted (i.e. whole trunk 
branch) and had to resort to 'unofficial' Fossil build (which may or may not 
have something to do with a recent bu‎g allegedly causing lost work; look it up 
on the list). I deducted that I should be OK, if I'm wrong - let me know, 
people :)

Use case: we have a long running dev project that will also inflict major 
changes to codebase organisation. There is also active development in other 
branches that will be merged to trunk on release and must be then merged to our 
project immediately, to allow us to pick up issues with our code ASAP. 

The team is also aided with external people who would be preferably constrained 
on what they can see in the current repo. 

Approach: export the current state of trunk to separate repo, develop our 
project in branch. Refresh trunk from our main repo when new release hits, and 
merge down regularly.

Steps:

1. Get a Win 64 (I'm on Win) build from Jan that will allow you to create new 
Fossil repo without initial checkin from here: 
http://sourceforge.net/projects/cyqlite/files/fossil/

This is crucial because the binary downloaded from Fossil site always creates 
the initial commit and you end up with two trunks that can't be merged because 
there are no common ancestors. 

2. f64 new sub-repo.fossil

3. f bundle export -R main-repo.fossil --branch trunk trunk.bundle

I had to get whole trunk branch:  the --from or --checkin‎ options didn't work 
because I ended up with missing content. It would be nice if there is an option 
to get the full artifacts, not just deltas (I thought --standalone was supposed 
to do that, but using that produced missing content too). It would be even 
nicer to have the bundle command that will create such a starting repo for you 
(e.g. bundle subrepo  -R main.fossil subrepo.fossil --checkin trunk). That way 
we could have the subrepo with arbitrary checkin from the main repo as the 
initial checkin, but be able to add subsequent ones later and merge. 

4. f bundle ‎import -R sub-repo.fossil trunk.bundle --force

5. f publish -R sub-repo.fossil trunk

That's it. After that I checked out subrepo and created a branch with couple of 
commits. Subsequent export / import (using --from and --branch trunk to 
restrict export to only the later trunk unexported checkins) "grafted" the 
sequence of main repo trunk check-ins at the correct place in subrepo trunk, 
and I was able to merge down to the subrepo branch without problems. 

I didn't test yet exporting the branch from subrepo, importing to main repo 
trunk and merging‎ back to main repo trunk, as I don't need that (our main repo 
will be retired and our subrepo will replace it). But that should work if the 
branch is created in main repo trunk before initial export, maybe even without 
that. 

Cheers,
Steve

  Original Message  
From: Ross Berteig
Sent: Tuesday, 22 September 2015 05:45

On 9/21/2015 10:32 AM, Warren Young wrote:
> On Sep 21, 2015, at 10:21 AM, Ron Aaron  wrote:
>>
>> I was hoping in vain for an easier solution.
>
> How would you imagine Fossil would support this, which would end up being 
> easier?

What about the Bundle mechanism?

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

[fossil-users] Graft a check-in from one repo to another?

[Steve Stefanovich]

Here’s the use case:



We’re moving from our existing large repo to several smaller ones, in order to 
clean up and make our builds more flexible.



One of new repos will start from the current state of old trunk. There are a 
couple of active development branches in old repo that will continue until 
completed.


When those are released and merged into old trunk, we then need to carry over 
at least the old trunk release check-in over into the new repo (and merge it 
down to dev branches there).



What’s the best way to go about this?



Is it possible to ‘graft’ a check-in (or, even better, a series of check-ins or 
a whole branch) from one repo to another?



I’ve experimented with bundle export/import with --force option, but I end up 
with check-ins with no common ancestors I can’t merge together.



Or is the best that could be done: close new repo trunk checkout, copy old 
trunk release checkout over it, reopen new repo checkout with --keep and commit 
the end result?

I guess if I could clone with similar options as in bundle export command, that 
would do the job.

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

[fossil-users] Cloning repos in local group?

[Steve Stefanovich]

Is there a‎ way for users to clone all repos in local group supplying user/pwd, 
so they can commit?

The 'master' repo can be cloned, but not the 'slaves' (i.e. repos that join the 
group, pointing to the master).

If no way, this is a major drawback for multi-repo setup vs single big one.

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

Re: [fossil-users] Cloning repos in local group?

[Steve Stefanovich]

‎It hasn't got anything to do with sub-repos. If you use login group, you 
cannot clone with authorisation any of the repos that joined the group, 
sub-repos or not.

This is not optimal because it forces you to duplicate user management in every 
repo, or use single big repo instead.

From: Stephan Beal


No. There is an 'all' command which can apply some commands (like 'pull') to 
all repos fossil knows about, but cloning isn't included...

Fossil doesn't directly support sub-repos/external modules, so it's only a 
drawback when trying to use Fossil outside of its comfort zone ;).

___
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] Multiple Projects in one Repo

[Steve Stefanovich]

‎Isn't the main annoyance the need to commit two times, one in nested checkout 
and one in the 'root' repo, and to try to keep timeline order in both?

How do you guys manage that - prevent committing/cloning to root and always use 
sub-repos?


  Original Message
From: Warren Young
Sent: Tuesday, 15 September 2015 03:58
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Multiple Projects in one Repo


On Sep 12, 2015, at 9:54 AM, Oliver Friedrich 
 wrote:
>
> with nested repositories my administration overhead would exceed even the 
> single repository solution, right?

The alternative to managing just one .fossil file is managing just one directly 
full of .fossil files.  Is that really such a big difference?

Note that “fossil serve” works the same when pointed to a directory full of 
fossils as it does when pointed at a single fossil, with the exception that the 
URLs are all one directory deeper.

There are two annoyances currently involved in managing nested repositories, 
which could in principle go away: the need to explicitly open the 
sub-repositories every time you open the primary, and the need to pass --nested 
to bypass the checks Fossil does for a parent containing .fslckout (a.k.a. 
_FOSSIL_).

Git solves this problem more elegantly with the submodule:

  https://git-scm.com/book/en/v2/Git-Tools-Submodules

In short, the main project simply declares that it needs other projects by URL. 
When you clone the main project, Git also clones the submodules into the 
correct place within the parent’s tree.

I use nested checkouts myself, though probably for a different reason than 
you’re proposing.  I have a top-level repository with many branches for older 
versions of the software, and all versions need to share a single set of 
Fossil-managed resource files.  These shared resource files must be versioned 
separately from the main repository files, but the current version must always 
be present underneath the main repository branches.  If I have three branches 
checked out, I need three additional nested checkouts of the shared repository.

It would be very nice if I could just open each branch, and have the 
subproject’s repo opened in its correct place, automatically.
___
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] merge after cherrypick plus edit does not identify GCA as I would like

[Steve Stefanovich]

‎Don't know if related, but I've also got unexpected results when subsequently 
merging cherrypick merges:

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg21107.html‎

(I need to come up with reproducible fossil example like you, but perhaps the 
description of the problem as is can still point someone‎ in the right 
direction.)

From: Eric Rubin-Smith‎
Sent: Tuesday, 15 September 2015 01:38
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] merge after cherrypick plus edit does not identify GCA 
as I would like


See the transcript below for gory details.  The summary is:

1. create a new file on trunk and check it in.
2. edit the file and check in on a branch (let's call it "beta")
3. trunk decides it wants that particular change set from step (2), so 
cherrypick it (assume in this example that other stuff is happening on the beta 
branch that we don't want in trunk at the moment, so a normal merge is not 
appropriate).
4. edit the same file on trunk and check it in
5. the "beta" branch now wants to merge the latest from trunk to continue work

==> It's noted as a merge conflict

This is because the GCA calculation does not seem to incorporate the cherrypick 
info (at least in this case).

Perhaps there is some deeper reason for this that I'm unaware of, but for this 
case the behavior is suboptimal.

Transcript illustrating the above:

eas@little:~$ fossil version
This is fossil version 1.33 [9c65b5432e] 2015-05-23 11:11:31 UTC
eas@little:~$ mkdir /tmp/fossil
eas@little:~$ cd !$
cd /tmp/fossil
eas@little:/tmp/fossil$ fossil new test.db
project-id: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
server-id:  ba2bb96bf830fa680389b425fa09c5dcfd5370c2
admin-user: eas (initial password is "dc73fc")
eas@little:/tmp/fossil$ mkdir sandbox
eas@little:/tmp/fossil$ cd !$
cd sandbox
eas@little:/tmp/fossil/sandbox$ fossil open /tmp/fossil/test.db
project-name: 
repository:   /tmp/fossil/test.db
local-root:   /tmp/fossil/sandbox/
config-db:/home/eas/.fossil
project-code: c3037e9c81eb4c3279dfc24f07579bfbe604ddee
checkout: 6bb0b6577411bd798631d137bf5b2d7d8fc3ac12 2015-09-14 15:28:16 UTC
tags: trunk
comment:  initial empty check-in (user: eas)
check-ins:1
eas@little:/tmp/fossil/sandbox$ echo 1.0 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil add VERSION
ADDED  VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Add version file"
New_Version: b6f302b927b0289feae9831c80f8b066f6e87d70
eas@little:/tmp/fossil/sandbox$ echo 1.1 > h^CRSION
eas@little:/tmp/fossil/sandbox$ set -o vi
eas@little:/tmp/fossil/sandbox$ echo 1.1b1 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit --branch beta -m "Start beta 
branch."
New_Version: ac64ec791f7be8601848e4c50a87dc54262cc659
eas@little:/tmp/fossil/sandbox$ fossil update trunk
UPDATE VERSION
---
updated-to:   b6f302b927b0289feae9831c80f8b066f6e87d70 2015-09-14 15:28:52 UTC
tags: trunk
comment:  Add version file (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge --cherrypick 
ac64ec791f7be8601848e4c50a87dc54262cc659
UPDATE VERSION
 "fossil undo" is available to undo changes to the working checkout.

eas@little:/tmp/fossil/sandbox$
eas@little:/tmp/fossil/sandbox$ fossil commit -m "Cherrypick version number 
change."
New_Version: 8a4693e6ce2faa5cf3cd1e5a839b33ba7c590d02
eas@little:/tmp/fossil/sandbox$ echo 1.1b1.01 > VERSION
eas@little:/tmp/fossil/sandbox$ fossil commit -m "More work on the trunk."
New_Version: cee15c31915298ecce84eb0b5aa9b7520e3c8b61
eas@little:/tmp/fossil/sandbox$ fossil update beta
UPDATE VERSION
---
updated-to:   ac64ec791f7be8601848e4c50a87dc54262cc659 2015-09-14 15:29:19 UTC
tags: beta
comment:  Start beta branch. (user: eas)
changes:  1 file modified.
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ fossil merge trunk
MERGE VERSION
* 1 merge conflicts in VERSION
WARNING: 1 merge conflicts
 "fossil undo" is available to undo changes to the working checkout.
eas@little:/tmp/fossil/sandbox$ cat VERSION
<<< BEGIN MERGE CONFLICT: local copy shown first <<<
1.1b1
=== COMMON ANCESTOR content follows 
1.0
=== MERGED IN content follows ==
1.1b1.01
>>> END MERGE CONFLICT >
eas@little:/tmp/fossil/sandbox$ exit




___
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] diff after update

[Steve Stefanovich]

‎This indeed looks the best way to go about it, on second thought.

From: Scott Robison


Here is the stash version of diff:

 fossil stash diff ?STASHID?
 fossil stash gdiff ?STASHID?

Why not do it the same way for undo?
___
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] diff after update

[Steve Stefanovich]

Clever, but awkward in my opinion; the first place to look for such a feature 
would be under diff command. At least for me, that is.

My vote is for diff --from|--to undo, where 'undo' is a special tag, same as 
'ckout' in different context. I think it fits in such paradigm nicely.

The person who names branches 'undo' can be perhaps warned in the command help 
to use the hash instead.

S.


  Original Message
From: Andy Bradford
Sent: Saturday, 12 September 2015 09:15
To: Richard Hipp
Reply To: Fossil SCM user's discussion
Cc: Fossil SCM user's discussion
Subject: Re: [fossil-users] diff after update


Thus said Richard Hipp on Fri, 11 Sep 2015 10:11:30 -0400:

> "fossil diff --versus-undo" maybe???

What if instead of making this a  feature of ``fossil diff'' it became a
feature of ``fossil undo?''

fossil undo --diff

Andy
--
TAI64 timestamp: 400055f36093
___
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] no unmerged forks / no common ancestor messages - bug?

[Steve Stefanovich]

I would appreciate if anyone on the list can clarify if the following is a bug 
or expected behaviour. I hope the diagrams will come out OK when this is posted.

I'm developing some features in 'x' branch, with a plan to merge periodically 
in another branch 'y', when stable. So I have added some files in 'x' to 
checkpoint (0), merged to 'y'.

X   Y
|   |
(0) M(0)

Next, I've added several more files in a check-in (1) to a branch 'y', but 
realised they had issues. I've edited that check-in (1) to be a start on new 
'mistake' branch, and modified the files in subsequent check-in (2) there. I 
merged 'mistake' back to my 'y', all good - commit to (3) on 'y'.

X   Y
|   |
(0) M(0)mistake
|   (1)
|   |
(3)M(2) 

Then I realised changes in (3) shouldn't be in 'y', but in 'x'.  No probs - 
I'll just do a baseline merge and put them there, I thought.

1. This is the first surprise. When doing 'f merge --baseline (1)' in branch 
'x' checkout, I get the message 'no unmerged forks of branch x'. What does 
this mean? I thought it would have pulled (1), (2)/(3) into branch 'x'.

So instead, I did two cherry-pick merges, one on top of the other: from (1), 
then (2) to 'x' - (3) was a no-op - committed, all good. Or so I thought.

X   Y
|   |
(0) M(0)mistake
|   |   (1)-|
|   |   |   |
|   (3)M(2) |
|   |   |   
(12)CM--|---|

2. Later, I had some more changes committed in 'x' (4)  and tried to merge them 
to 'y'. Another surprise: when doing 'f merge x' in branch 'y' checkout, I get 
'no common ancestor' warnings on *all* files that I have added previously in 
both (0) *and* (1). Why is this?

X   Y
|   |
(0) M(0)mistake
|   |   (1)-|
|   |   |   |
|   (3)M(2) |
|   |   |   
(1,2)CM-|---|
|   |
(4)---M(warnings)

So I lost modifications on some of those files that were committed in (4). 
However, the *new* file I committed in (4) was successfully 'added_by_merge'.

This does not make sense to me. I thought that files that have been merged into 
'y'(3), and then later cherry-pick merged to 'x'(1,2), would have had the 
common ancestors in (1) and (2). I also don't understand why am I receiving 
such warnings for files that have been committed in 'X' in (0) and successfully 
merged to 'Y' at the beginning.

Is this a bug?

Fossil 1.32 [6c40678e91] downloaded from Fossil site, Windows.

Cheers,
Steve
___
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] fine(r) commit granularity

[Steve Stefanovich]

 From: Paolo Bolzoni
 Sent: Wednesday, 29 July 2015 08:38
 
 fossil commit filename
 might help you in your problem?

It gets messy when there is a number of files, on Windows at least where using 
pipes and xargs is limited compared to Unix.

 On Tue, Jul 28, 2015 at 5:32 PM, Gour g...@atmarama.net wrote:
 
  what do you think about such feature, iow. split commit within one
  file in smaller chunks when one forgets to ’safe often, commit often’
  or simply wants to divide single commit into several ones?

I think it would be useful, especially with complicated merges or when you have 
to revert bits out of the release. (I assume you propose something along the 
lines fossil commit --incremental where you would get prompted if you want to 
commit a particular file or not.)

I use stash now to deal with this, but this would be easier.

Cheers,
Steve
___
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] imported from git: a question about performances and about tags

[Steve Stefanovich]

Most likely it's the checksum calculation ‎of the checked-in files that is 
slowing things down for you.

Do 'fossil set repo-cksum 0' and then try committing again.

  Original Message
From: Luca Ferrari‎
Sent: Tuesday, 26 May 2015 19:37‎
To: Fossil SCM user's discussion‎
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] imported from git: a question about performances 
and about tags


On Tue, May 26, 2015 at 8:22 AM, Luca Ferrari fluca1...@infinito.it wrote:
 On Mon, May 25, 2015 at 2:30 PM, Richard Hipp d...@sqlite.org wrote:
 How many files are in a single check-out.


 The working directory is made by 39k files, but around 3k are in the
 repository (the others are blobs and not versioned files).

In the case it is useful for a better analysis I tried cutting to half
the number of not versioned files, but nothing changed.
In particular I've seen that in the commit workflow:

% fossil commit -m Aggiunti commenti   # 1 file
#... aorund 10 seconds
New_Version: f896fd210ce4d03e90cdd856870be5b341d278ad
# ...around 17 seconds

and to be a little more accurate:

% time fossil commit -m Aggiunti commenti # 1 file
New_Version: 93c5fb6e88aaa60eb4524d1d4415d28ee8a72c9b
fossil commit -m Aggiunti commenti  21,82s user 5,21s system 96% cpu
28,144 total


In order to exclude some file system, disk or hardware problem I ran
the following on the same checkout:

% time git commit -m Fossil manual sync
[master 2b343e8] Fossil manual sync
 6 files changed, 97 insertions(+), 171 deletions(-)
git commit -m Fossil manual sync  0,03s user 0,03s system 74% cpu 0,074 total

Hope this can provide any hint.

Thanks,
Luca
___
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] Allow checkins on another repo

[Steve Stefanovich]

What about nested checkouts? Which repo should it check to? I presume the first 
_FOSSIL_ it finds.

What if you make a typo that results in the path which is a valid changed file 
in unintended checkout? That would result in committing to wrong repo.

‎This could easily (certainly to me, at least) happen in case of multiple 
checkouts from the same repo (e.g. feature or maintenance branches).

But to be fair, I'd rarely - if ever - commit from another directory. I always 
cd to 'correct' one, do a stat/gdiff beforehand, etc.


  Original Message
From: Warren Young
Sent: Wednesday, 13 May 2015 05:39
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] Allow checkins on another repo


“fossil ci” currently allows you to specify file or directory names, which 
causes it to restrict the checkin to the named entities.

This is very useful within a single repository, but it breaks down when you try 
to use it with multiple repo checkouts.  Fossil doesn’t take those names into 
account when locating the .fslckout file; it appears to only use CWD.

This causes extra work when you are working on two different repositories at 
once, cd’d into one but changing files in the other.  If you say something like:

$ fossil ci ~/some/other/repo/file.c

…then fossil will complain that file.c is not part of the current repo.  It 
makes you cd over to ~/some/other/repo just to check that file in, then cd 
back.  Fossil should be smart enough to realize that file.c belongs to a 
*different* repo and DTRT.
___
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] How about renaming a fork to fork-*? (Was: Two trunks?)

[Steve Stefanovich]

Let me rephrase - maybe I was a bit ambiguous what I meant.
‎
On pull/update, when fork happens locally, ‎the code would automatically do 
what currently happens when someone edits the check-in and puts it on a new 
branch. 

So on a local repo/check-out, developer sees he's now on (latest leaf of) 
fork-trunk‎ branch, instead of thinking he's on a trunk while in reality he's 
on a fork of the trunk which is named the same.

Dev merges back to trunk and commits, or ‎edits the beginning of the fork (if 
he has a sequence of check-ins) to a branch name he likes in case he wants to 
keep it as a branch, and pushes. 

So what would ‎end up on the server that is strange or mysterious on such push 
apart from an extra tag, fork-trunk? What am I missing?
‎
‎
  Original Message  
‎
From: Richard Hipp
Sent: Saturday, 18 April 2015 21:50
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two
trunks?)

On 4/18/15, Steve Stefanovich s...@stef.rs wrote:
 How about if the fork happens, simply change the tag automatically to
 'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or
 just tag it as 'fork', on commit?


When the artifacts that comprise a fork are received, the server has
no way of knowing that new artifacts that resolve the fork (either by
merging or by moving it onto a branch) will not be received within the
next few milliseconds. Hence, what you suggest could result in
strange and mysterious changes occurring to the check-in topologies
during a push. Very undesirable, I think.

-- 
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] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Steve Stefanovich]

I can imagine a lot of people being annoyed if auto resolution was to add a 
file previously deleted from a branch back to the branch. I can see that being 
every bit as confusing to them as it not being re-added is to you. Just as my 
deleted text a month ago was to me.

The difference is that re-adding is showing up in 'fossil status', which is 
then easy to reverse by grepping it's output and piping to delete before 
commit; while for no-op, as currently is the case, you are not aware there is a 
potential problem at all. And if/when you figure out that files are missing, 
you'd have to resurrect and manually add them one by one.

But I wouldn't mind if, instead of no-op, status just shows that the ancestor 
was removed and current edits are therefore ignored. I can then equally grep 
for it and then bulk add it, if necessary. It would be interesting to know what 
others on the list think. It would be more cumbersome to describe, in my 
opinion - see below example.

I think the crucial thing here is the distinct indicator by the merge that this 
situation is encountered, so you can then choose to act if appropriate. How it 
is auto-resolved is less important.

For example, this indicator could be a status like 'CONFLICT', but would be 
auto-resolved to allow commit. For example, 'READDED_BY_MERGE' or, in your 
case,  'KEPT_DELETED_BY_MERGE' or 'IGNORED_CHANGES_ANCESTOR_MISSING'.

On Thu, Apr 16, 2015 at 9:15 PM, Steve Stefanovich 
s...@stef.rsmailto:s...@stef.rs wrote:
?I'd argue this is not intuitive, especially to a new Fossil user. Losing the 
file like this and not reporting at least as a warning seems like a wrong 
design choice, to me.

I'd agree it is not intuitive, as it took some hours of my time when I thought 
I'd found a bug a month ago to trace through the code looking for a flaw that 
didn't exist. I had told it at one point in time to merge in a deletion into my 
branch, and so when it came time to play catch up to trunk, it did what I had 
told it to do previously: Keep text previously deleted out of the new merge, 
even though in this case I needed to readd something due to other changes in 
fossil.

I actually like flagging the file as a conflict, with auto-resolution being to 
keep (re-add) the file. If this is tagged distinctively, then it is very easy - 
when you don't want the files re-introduced - to grep the output of 'fossil 
status' and bulk delete such files before committing the merge.

I can imagine a lot of people being annoyed if auto resolution was to add a 
file previously deleted from a branch back to the branch. I can see that being 
every bit as confusing to them as it not being re-added is to you. Just as my 
deleted text a month ago was to me.

But at least a warning would be very useful. We already have warnings when 
files don't have common ancestors while merging (the cause of which confused me 
enough times and is probably related to this).

How about this scenario:

1. Trunk is the mainline branch from which releases are made.
2. Feature is a branch for ongoing development of some feature.
3. Periodically you merge trunk into feature so that you don't drift too far 
(up to and including just before the final merge back to trunk).
4. In the end, you merge from the feature back to trunk when everything is 
ready for release.

I think in this case you'd get the warning you seek because in the parent 
branch it had been deleted while being edited in the child branch (the nearest 
common ancestor was on trunk).

I think you're right about the common ancestor confusion. I certainly can see 
the point about deletion from one branch and edits in another branch being 
arguably a conflict requiring resolution. I'm just can't think of a better way 
to handle it than at present. This is probably why I don't get paid the big 
bucks.

--
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] How about renaming a fork to fork-*? (Was: Two trunks?)

[Steve Stefanovich]

Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, 
but just the quote without my reply).

‎What I meant to say here is that the whole confusion about forks is due to the 
fact that they branch out under the same tag.  I can't see the case where is 
this ever desirable.

How about if the fork happens, simply change the tag automatically to 
'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just 
tag it as 'fork', on commit?

That would be very visible, either prompting people to merge back and close the 
fork, or to rename the 'fork-' tag to meaningful branch name.

From: Ron W
Sent: Saturday, 18 April 2015 03:00
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two 
trunks?)


Hello,

Did you mean for your reply to go only to me? You did not CC the Fossil list.

On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich 
s...@stef.rsmailto:s...@stef.rs wrote:

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a fork not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove fork status.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.orgmailto: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] Fw: How about renaming a fork to fork-*? (Was: Two trunks?)

[Steve Stefanovich]

Ah, wonders of fiddling with email on mobile... (BTW, it did go on the list, 
but just the quote without my reply).

‎What I meant to say here is that the whole confusion about forks is due to the 
fact that they branch out under the same tag.  I can't see the case where is 
this ever desirable.

How about if the fork happens, simply change the tag automatically to 
'fork-trunk' (i.e. prefix the existing repeating tag(s) with 'fork'), or just 
tag it as 'fork', on commit?

That would be very visible, either prompting people to merge back and close the 
fork, or to rename the 'fork-' tag to meaningful branch name.

From: Ron W
Sent: Saturday, 18 April 2015 03:00
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] How about renaming a fork to fork-*? (Was: Two 
trunks?)


Hello,

Did you mean for your reply to go only to me? You did not CC the Fossil list.

On Thu, Apr 16, 2015 at 9:07 PM, Steve Stefanovich 
s...@stef.rsmailto:s...@stef.rs wrote:

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a fork not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove fork status.


___
fossil-users mailing list
fossil-users@lists.fossil-scm.orgmailto: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] How about renaming a fork to fork-*? (Was: Two trunks?)

[Steve Stefanovich]

From: Ron W
Sent: Friday, 17 April 2015 11:04
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Two trunks?


On Thu, Apr 16, 2015 at 8:25 PM, Andy Bradford 
amb-fos...@bradfords.orgmailto:amb-fos...@bradfords.org wrote:
And a fork that ends in being merged is also no longer a fork.

I disagree. While it might be the most common case, merging does not explicitly 
state any intent beyond the merge itself, even a full merge. After all, a merge 
doesn't automatically close a named branch. So why would a merge automatically 
make a fork not a fork?

Closing it or making it the start of a new, named branch explicitly indicate an 
intent to remove fork status.

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

[fossil-users] Merging deleted files (Was: Merge - including files from other branches - best practice?)

[Steve Stefanovich]

‎I'd argue this is not intuitive, especially to a new Fossil user. Losing the 
file like this and not reporting at least as a warning seems like a wrong 
design choice, to me.

I actually like flagging the file as a conflict, with auto-resolution being to 
keep (re-add) the file. If this is tagged distinctively, then it is very easy - 
when you don't want the files re-introduced - to grep the output of 'fossil 
status' and bulk delete such files before committing the merge.

But at least a warning would be very useful. We already have warnings when 
files don't have common ancestors while merging (the cause of which confused me 
enough times and is probably related to this).

Richard, do you have a view on this?


From: Scott Robison
Sent: Friday, 17 April 2015 08:37
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Merge - including files from other branches - best 
practice?


On Thu, Apr 16, 2015 at 4:10 PM, Steve Stefanovich 
s...@stef.rsmailto:s...@stef.rs wrote:
‎I think what happened is that the file got deleted in the trunk (by another 
merge) and the OP expected it to be re-added by the last merge because the file 
was  there.

Is this by design? I would've expected it too.

It is by design. Merging isn't always intuitive, and certainly there could be a 
bug in it. I thought I'd found one a month or so ago but after debugging and 
going through the code with a fine toothed comb, I realized I was wrong. It was 
related to edits to the same file in the same place and it was not obviously 
why previously merges had made certainly lines of code unavailable in the 
merge conflict resolution.

Consider this (commits are assumed to happen at each stage):

1. Trunk commit includes file foo.
2. Branch is created from trunk (which includes foo).
3. Edits are made on branch.
4. Merged from branch to trunk (edits now reflected on trunk).
5. File is removed from trunk.
6. More edits are made on branch.
7. Merged from branch to trunk (there is no foo in trunk to which to apply the 
edits, and foo was not *added* to the branch).

Believe me, I understand, merging is not always intuitive if you don't have 
absolute complete awareness of the state of all files in both branches in every 
commit on each branch. In this case, the fact that the file was removed from 
trunk meant there was no where to put the edits from the branch.

The only other way of resolving this would be to give some sort of merge 
conflict that the edits from branch are to an empty file on trunk, but then one 
could argue I deleted foo from trunk, don't waste my time with conflict 
resolution reports.

SDR

  Original Message
From: Warren Young
Sent: Friday, 17 April 2015 06:46
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Merge - including files from other branches -   
best practice?


On Apr 16, 2015, at 2:44 PM, Warren Young 
w...@etr-usa.commailto:w...@etr-usa.com wrote:

 On Apr 16, 2015, at 10:47 AM, Johan Kuuse jo...@kuu.semailto:jo...@kuu.se 
 wrote:

 In c-stdin, I created the file b64.c

 That’s not what this says:

Also, notice that the checkin that claims to have created b64.c actually 
modifies the copy created on the trunk:

  http://kuu.se/fossil/b64.cgi/info/71a14569b473e988f5824c10d09506e67f32d070
___
fossil-users mailing list
fossil-users@lists.fossil-scm.orgmailto: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.orgmailto:fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users



--
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] file-filter branch plead

[Steve Stefanovich]

Yes, from the shell command line.

S.
  Original Message
From: jungle Boogie
Sent: Wednesday, 1 April 2015 01:18
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: Re: [fossil-users] file-filter branch plead


Hi Steve,
On 30 March 2015 at 15:53, Steve Stefanovich s...@stef.rs wrote:
 ‎
 Yes, I find file filtering useful too. Even better, it should be incorporated 
 in search drop-down list. FWIW, I manage now by ' f sett manifest on' and 
 grepping the manifest file.

You do this from the cli only, correct?


 http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg19455.html


Good points in article and hopefully we'll see some happen. Since the
file filter already exists, it's the easiest to implement but I
suppose there's not much of a draw for it and that's why it's not in
Fossil.

--
---
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] file-filter branch plead

[Steve Stefanovich]

‎
Yes, I find file filtering useful too. Even better, it should be incorporated 
in search drop-down list. FWIW, I manage now by ' f sett manifest on' and 
grepping the manifest file. 

Apart from common scenarios (don't remember the‎ file name exactly, multiple 
same/similar file names) you've mentioned, I'd also add a a case of searching 
in previous commits' manifests. 

For example, I know there was a file named 'foo', but someone renamed or 
deleted it. It would be useful to be able to locate the original file and then 
jump to its history, so you can see where is it now, annotate/blame etc. 

Cheers,
Steve

P.S. BTW, Fossil *does* search in the code, if you set the document search to 
'*' (or *.c or *.rb etc.) It needs the links to be named properly though, and 
have them force MIME type to 'txt', as discussed here (points 3. and 4.) :

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg19455.html


‎
  Original Message  
From: jungle Boogie
Sent: Friday, 27 March 2015 10:12
To: Fossil SCM user's discussion
Reply To: Fossil SCM user's discussion
Subject: [fossil-users] file-filter branch plead

Hi All, drh,

Is anyone else interested in the file-filter branch seen here:
https://www.fossil-scm.org/index.html/timeline?n=100r=file-filter

I find it very useful because I may not always remember the path...

Thanks to Fossil being backed by sqlite, we have a great search
feature but it doesn't search the files/code section‎...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] can't add tickets to fossil-scm anymore?

[Steve Stefanovich]

Looks like anon user can’t create new tickets anymore. Is this on purpose?

I’d like to raise 3. (file name) and 4. (MIME type) as outright bugs, 4. being 
particularly annoying, for drh and/or others to have a look at when they have 
more bandwidth.

Cheers,
Steve

P.S. Would be interested in what other members of the list think on bullet 
points below. Surely others are using new search functionality too?...


From: Steve Stefanovich
Sent: Wednesday, 11 March 2015 14:19
To: Fossil SCM user's discussion
Subject: Displaying new search results

‎The new search functionality is awesome and quick - thanks, drh. It is a huge 
step forward to make Fossil usable for non-programmers, i.e. GUI-only users 
(managers, testers, documentation writers).

It's not quite there yet, IMHO. drh - and other valued contributors - what do 
you think about fixing or improving the following:

(Fossil 1.31 Win binary‎, /search page)

1. How about displaying the search results in table with sortable columns, 
similar to /brlist and ticket reports? Suggested columns would be mtime, type 
(doc/check-in/ticket etc.), creator username, filename (wiki title, ticket 
subject) and search hit snippet. (Add commit hash if 5. below is implemented).

This would cater for much more common use case where you can't remember - or 
don't know - the 'unique enough' search keywor‎d(s) to get relevant hits, but 
you do know a person who updated the content or roughly when it was done. By 
sorting on columns you can quickly zoom in on what's relevant even if there are 
lots of search hits due to common keyword.

2. Include search on full path filenames too. Sometimes I'm interested in 
specific file, but remember only roughly what it is called or where is it 
located. This would be even more useful if search can traverse commits and show 
deleted/renamed versions as well; sometimes I know there was a file with 'foo' 
in its name that I can't find anymore because someone has deleted or renamed it.

3. If the file extension is not wiki, the hyperlink to go to contains the first 
line of the file instead of the filename. So if I enable search of the source 
code by adding, say *.c in search admin page, instead of the full path 
filenames being displayed, I get the first line of the comment or copyright 
notice. It should be full path filename.

4. The search result hyperlinks should have the ?mimetype=text/plain suffix 
always set, otherwise if they are not wikis, then ‎they get served as 
downloads. It is more conceivable that I'd want to look at the file content 
instead. If I need to download, I can always quickly delete the suffix and get 
it.

5. Search over past commits.  This probably deserves a separate discussion on 
its own. I hope that if it can be invoked with params that limit the keyword 
search on file extension, tag, date or number of hits, it can work fast enough 
even as full text search.  The challenge would be how to display the context 
for different use cases.

Thanks for Fossil, it is really useful software.

Cheers,
Steve


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

[fossil-users] can't add tickets to fossil-scm anymore?

[Steve Stefanovich]

Looks like anon user can't create new tickets anymore. Is this on purpose?

I'd like to raise 3. (file name) and 4. (MIME type) as outright bugs as per 
original message here:

http://www.mail-archive.com/fossil-users%40lists.fossil-scm.org/msg19455.html


Cheers,
Steve

P.S. Would be interested in what other members on points raised there. Surely 
others are using new search functionality too?...

P.P.S. Apologise in advance if this comes out as double-post. My posts (Outlook 
client/Exchange server) does not appear on the list - only the replies, it 
seems.
___
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] Select specific changes within files

[Steve Stefanovich]

‎I feel exactly like below little excerpt from recent drh's email on the 
subject. There other bits of Fossil that are more important - to me, at least - 
to spend time on, like polishing search, improving wiki and ticketing default 
setup, etc. 

If we are discussing partial, I'm more interested in partial checkouts than 
partial commits, i.e. having the ability to checkout a specific directory only. 
Now that would be useful for us with big source trees where there are third 
party components included.

  Original Message  
From: Richard Hipp
Sent: Saturday, 21 March 2015 04:05
Subject: Re: [fossil-users] Select specific changes within files

...We shouldn't waste too much time implementing that capability when there are 
other more useful features that could be added instead...
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

[fossil-users] Fixing search results

[Steve Stefanovich]

So no reactions about search changes suggestions? It would be good to fix 3. 
and 4. at least, if 1. is too difficult. (5. is for further discussion)

S.

From: Steve Stefanovich‎
Sent: Wednesday, 11 March 2015 14:18‎
To: Fossil SCM user's discussion
Subject: Displaying new search results


‎The new search functionality is awesome and quick - thanks, drh. It is a huge 
step forward to make Fossil usable for non-programmers, i.e. GUI-only users 
(managers, testers, documentation writers).

It's not quite there yet, IMHO. drh - and other valued contributors - what do 
you think about fixing or improving the following:

(Fossil 1.31 Win binary‎, /search page)

1. How about displaying the search results in table with sortable columns, 
similar to /brlist and ticket reports? Suggested columns would be mtime, type 
(doc/check-in/ticket etc.), creator username, filename (wiki title, ticket 
subject) and search hit snippet. (Add commit hash if 5. below is implemented).

This would cater for much more common use case where you can't remember - or 
don't know - the 'unique enough' search keywor‎d(s) to get relevant hits, but 
you do know a person who updated the content or roughly when it was done. By 
sorting on columns you can quickly zoom in on what's relevant even if there are 
lots of search hits due to common keyword.

2. Include search on full path filenames too. Sometimes I'm interested in 
specific file, but remember only roughly what it is called or where is it 
located. This would be even more useful if search can traverse commits and show 
deleted/renamed versions as well; sometimes I know there was a file with 'foo' 
in its name that I can't find anymore because someone has deleted or renamed it.

3. If the file extension is not wiki, the hyperlink to go to contains the first 
line of the file instead of the filename. So if I enable search of the source 
code by adding, say *.c in search admin page, instead of the full path 
filenames being displayed, I get the first line of the comment or copyright 
notice. It should be full path filename.

4. The search result hyperlinks should have the ?mimetype=text/plain suffix 
always set, otherwise if they are not wikis, then ‎they get served as 
downloads. It is more conceivable that I'd want to look at the file content 
instead. If I need to download, I can always quickly delete the suffix and get 
it.

5. Search over past commits.  This probably deserves a separate discussion on 
its own. I hope that if it can be invoked with params that limit the keyword 
search on file extension, tag, date or number of hits, it can work fast enough 
even as full text search.  The challenge would be how to display the context 
for different use cases.

Thanks for Fossil, it is really useful software.

Cheers,
Steve



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

[fossil-users] Displaying new search results

[Steve Stefanovich]

‎The new search functionality is awesome and quick - thanks, drh. It is a huge 
step forward to make Fossil usable for non-programmers, i.e. GUI-only users 
(managers, testers, documentation writers).

It's not quite there yet, IMHO. drh - and other valued contributors - what do 
you think about fixing or improving the following:

(Fossil 1.31 Win binary‎, /search page)

1. How about displaying the search results in table with sortable columns, 
similar to /brlist and ticket reports? Suggested columns would be mtime, type 
(doc/check-in/ticket etc.), creator username, filename (wiki title, ticket 
subject) and search hit snippet. (Add commit hash if 5. below is implemented).

This would cater for much more common use case where you can't remember - or 
don't know - the 'unique enough' search keywor‎d(s) to get relevant hits, but 
you do know a person who updated the content or roughly when it was done. By 
sorting on columns you can quickly zoom in on what's relevant even if there are 
lots of search hits due to common keyword.

2. Include search on full path filenames too. Sometimes I'm interested in 
specific file, but remember only roughly what it is called or where is it 
located. This would be even more useful if search can traverse commits and show 
deleted/renamed versions as well; sometimes I know there was a file with 'foo' 
in its name that I can't find anymore because someone has deleted or renamed it.

3. If the file extension is not wiki, the hyperlink to go to contains the first 
line of the file instead of the filename. So if I enable search of the source 
code by adding, say *.c in search admin page, instead of the full path 
filenames being displayed, I get the first line of the comment or copyright 
notice. It should be full path filename.

4. The search result hyperlinks should have the ?mimetype=text/plain suffix 
always set, otherwise if they are not wikis, then ‎they get served as 
downloads. It is more conceivable that I'd want to look at the file content 
instead. If I need to download, I can always quickly delete the suffix and get 
it.

5. Search over past commits.  This probably deserves a separate discussion on 
its own. I hope that if it can be invoked with params that limit the keyword 
search on file extension, tag, date or number of hits, it can work fast enough 
even as full text search.  The challenge would be how to display the context 
for different use cases.

Thanks for Fossil, it is really useful software.

Cheers,
Steve



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