On 1 Nov 2010, at 01:43, D. Richard Hipp wrote:
> The repository is probably fine - it is your checkout that is out-of-date.
> Please try:
>
> fossil close
> fossil open ../old-repo.fossil
>
> Please let us know if that doesn't fix your problem.
Yes! That fixed it :-) Thanks.
(The clo
Hi,
I've got a fossil repo I've not used for about a year and a half. I've updated
my fossil binary a few times and moved machine (architecture, from PPC Mac to
Intel Mac) in that time. When I try to perform operations, I get this result:
> BetfairDev # fossil chan -v
> fossil: SQLITE_ERROR: n
> So I thought that might have meant multiple, distinct trees, similar to
> how one can have branches in Git with independent directory structures
> but all separate from each other, even if they are stored in the same
> repository.
>
> I'm wondering how difficult/desirable it might be to support
Hi,
My current practice is to have a fossil repo per project. I've committed the
(cardinal) sin of duplicating shared files between projects. I want to fix
this.
Conceptually I'd like to have one huge repo for everything (individual projects
and all common files), and maintain working copies
On 27 Jul 2010, at 11:37, Zed wrote:
> But again, none of this matters for my point. I'm not talking about
> wiki, I'm talking about HTML documentation. If there was a way to
> generate HTML using any of the many docs generators out there, and then
> check it into fossil so that fossil styles i
On 27 Jul 2010, at 11:37, Rene wrote:
> Maybe it is good to take a step back and state first what the purpose
> is of the wiki system in fossil.
> Which will give guidance to us all.
Excellent question! I don't use it at all, so I've no clue why it generates so
much fuss :-) (I'm a sole develope
Problem
I forget to add in new files that I create. This leads to me creating
one or more check-ins that aren't a complete representation of the
working set of files. Worse, the new files are often the ones that I'm
working on most actively because they're new.
Suggestion
Problem
I forget to add in new files that I create. This leads to me creating
one or more check-ins that aren't a complete representation of the
working set of files. Worse, the new files are often the ones that I'm
working on most actively because they're new.
Suggestion
On 8 Feb 2010, at 16:53, D. Richard Hipp wrote:
> Test version at http://www.fossil-scm.org/test/fossil/timeline?
> n=20&y=ci - please provide feedback.
>
> Other interesting views:
>
> http://www.fossil-scm.org/test/fossil/timeline?n=20&y=ci&b=2010-01-25
> http://www.fossil-scm.org/test/
On 18 Dec 2009, at 00:01, D. Richard Hipp wrote:
> The manifest and manifest.uuid files are not used by Fossil. Fossil
> makes those files available for the convenience of the application and
> the application's makefile. For example, the makefile for SQLite
> extracts information from its man
I described this a few days ago, but not very coherently. Here's
another try. I'm happy to bung this in a tracker somewhere if someone
hands me a url.
Problem:
I believe there is a bug with "fossil mv": it lets me move a file
outside of the change controlled tree, at which point ther
I offered a (horrible) work around. Fortunately, I thought better of
it for my particular case, where my working set was in the middle of a
merge.
Instead, I've used sqlite on the command line to find a row in the
vfile table and correct it's "pathname" so it's where I meant to move
it to
Hi,
I've managed to get my working copy in to a funny state. I performed a
"fossil mv" on a file, and gave a destination outside of the checkin
tree. Fossil was happy to perform this operation, but now I'm not able
to correct the mistake. If I try to move the file back in, I get the
error
On 9 Dec 2009, at 21:21, fossil-users-requ...@lists.fossil-scm.org
wrote:
> Which is exactly why "fossil rm *.foo" should delete *.foo from the
> file system as well as from the repository. If you forget, and do "rm
> *.foo", then you can ask fossil to give you the files back, and then
> do "f
Hi,
Three things keep catching me with Fossil. Am I being stupid and
missing something? If not, I'd like to propose them as areas for
enhancement.
1) I'd like to be able to delete a folder. I think Fossil doesn't
track folder, which is fine – if I say:
fossil rm
… I'd like it to be
> I'm not going to bother stopping it, nor did I plan to. I was only
> showing
> you what the first 10m showed. Now?
>
> YES: 13
> NO: 3
>
> Any: 13
> Markdown: 3
> Creole: 1
Don't forget to add in the "Apathetic" or "Not sure"s. I'm so unsure
and apathetic, I don't remember which one I picked
Joshua Paine wrote about having a script recursively add and remove to
make the repository reflect what is currently on disk (please correct
me if this isn't a fair summary!).
While this might be sufficient for some usage patterns, I don't think
this is a great solution in general. The major
On 21 Oct 2009, at 18:52, fossil-users-requ...@lists.fossil-scm.org
wrote:
> Two highly skilled programmers failed to notice an important feature
> of fossil. This screams "User Interface Problem!" Does anybody have
> a suggested remedy?
The "Leaves" and "Timeline" views could be modified so
On 8 Oct 2009, at 13:00, fossil-users-requ...@lists.fossil-scm.org
replied about creating a retrospective branch:
> This is easier to do from the web interface.
>
> (1) Bring up the web interface (by typing "fossil ui" from an open
> checkout)
>
> (2) On the timeline, locate the check-in that y
Hi,
A project I have has one branch – the trunk. I've been away from this
project for a few weeks, and on returning to it, I've decided that the
most recent commit (in which I switched over to using OpenGL for
rendering) is not something I want to pursue at the moment. I would
like to plac
On 4 Oct 2009, at 13:00, fossil-users-requ...@lists.fossil-scm.org
wrote:
> 5- How to make a gdiff of two repository versions (not a diff a
> gdiff)? I've tried to make a gdiff of current version with a
> repository version (the first chars of the sha of the version) , like
> this:
>
>fossi
Hi,
I'd like to have a way to revert several files at a time, and
particularly, to revert all files that match a glob pattern. Eg, I'd
like to be able to do:
fossil revert *
To revert everything in this folder, and
fossil revert ImageController.*
to revert ImageController.h
I wrote:
> Hmmm. Presumably the solution would be to either have opendiff support a
> "synchronous" flag, or some kind of delay before return, or to introduce
> a hacky delay in to gdiff invocation?
In case this is useful to anyone - if FileMerge is already running, then
things seem to work o
Hi,
OS X has a (pretty tasty) graphical merge tool called FileMerge, which
can be invoked from the shell using the command 'opendiff'.
The opendiff command's syntax is:
opendiff file1 file2 [-ancestor ancestorFile] [-merge mergeFile]
I've tried setting this as fossil's gdiff client, and it
Perhaps this is too heavy weight (and perhaps it's really obvious), but
a sensible approach might be to provide a set views to the users, rather
than direct table access?
* These could probably provide more suitable information for
scripting than raw tables,
* They would provide abstracti
Eric:
> OK, I see the point, but for many people the working directory usually
> contains lots of extra files - the results and intermediates of a build.
> The result of a "fossil extra" would not be very helpful in this case. I
> suspect it of being one of those cases where it would be difficult
Thanks Eric and Michael.
Ah - I didn't make myself at all clear here, sorry.
What I'm after is for something like "fossil change" to also show
_extra_ files that "fossil extra" would show (_not_ _added_ files as I
incorrectly said in my post. Sorry.). So If I do this:
EdgeRuby # fossil change
Hi, is there a fossil command that will summarise both the files that I
have changed, and any files that I have added? Or is it possible for me
to configure one of the existing commands to show me both of these things?
This seems to me as if it would be pretty useful, but perhaps there is a
goo
28 matches
Mail list logo
