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
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
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-
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
> (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
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
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
___
>> 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
> 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
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
> > 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
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:
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
> >> 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
> 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.
___
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
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
This reads better then previous version and more detail is given, thanks.
The very 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
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:
>> 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
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
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"
>> 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
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
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
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
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
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.
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:
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,
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
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
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
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
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
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
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
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
, 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
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
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
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
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
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
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
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
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
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
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
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
50 matches
Mail list logo
