On Sat, Aug 27, 2011 at 6:13 AM, Stephan Beal wrote:
> [stephan@cheyenne:~/cvs/fossil/whio/pfs]$ f stash pop
> f: ./bld/blob_.c:786: blob_write_to_file: Assertion
> `(pBlob)->xRealloc==blobReallocMalloc ||
> (pBlob)->xRealloc==blobReallocStatic' failed.
> Aborted
> [stephan@cheyenne:~/cvs/fossil/
On Sat, Aug 27, 2011 at 4:22 AM, Dmitry Chestnykh
wrote:
> I have just commited the code to update local tables.
>
Yeah :). Stash works again :). Well, halfway...
This is fossil version 1.19 [8c0f4bc718] 2011-08-27 01:21:42 UTC
save works, but pop/apply don't:
[stephan@cheyenne:~/cvs/fossil/wh
On Aug 27, 2011, at 3:43 AM, Stephan Beal wrote:
> There is no --branch option to the open command. i probably could have passed
> the branch name as the version (didn't think about it and never needed it
> before). No big deal. The few changes i munged were about to be thrown out
> anyway.
Ye
On Sat, Aug 27, 2011 at 2:36 AM, Dmitry Chestnykh
wrote:
> > What i was trying to do was stash uncommitted changes from the branch so
> that i could go back to the trunk. When stashing failed, a close left me
> with the branch's state + my uncommitted changes. A re-open brought me to
> the trunk,
> What i was trying to do was stash uncommitted changes from the branch so that
> i could go back to the trunk. When stashing failed, a close left me with the
> branch's state + my uncommitted changes. A re-open brought me to the trunk,
> and my pre-commit state is such that the trunk thinks it
On Sat, Aug 27, 2011 at 2:09 AM, Dmitry Chestnykh
wrote:
> Yeah, I haven't written code to alter stash and undo tables that already
> exist in local _FOSSIL_ database with the new isLink column yet. If you
> close and reopen repository, they'll be recreated.
>
Doh... that was a bad idea. My chang
At 04:24 PM 8/26/2011, Remigiusz Modrzejewski wrote:
>On Aug 26, 2011, at 10:29 PM, Tomek Kott wrote:
>>>
>>> http://www.sqlite.org/src/timeline?n=200
>>>
>>> Side note: is it me, or are the lines only showing up on the
>normal (n=20)
>> timeline view? Perhaps the lines would just be too com
On Aug 27, 2011, at 2:00 AM, Stephan Beal wrote:
> Possible bug: can't stash :(
>
> [stephan@cheyenne:~/cvs/fossil/whio]$ f stash save -m 'some threading code i
> will probably toss out.'
> f: SQLITE_ERROR: table stashfile has no column named isLink
> f: table stashfile has no column named isLink
On Fri, Aug 26, 2011 at 7:30 PM, Richard Hipp wrote:
> It's been a long time since there has been an official release of Fossil.
> Probably I should do another soon
>
Possible bug: can't stash :(
[stephan@cheyenne:~/cvs/fossil/whio]$ f stash save -m 'some threading code i
will probably tos
On Aug 26, 2011, at 10:29 PM, Tomek Kott wrote:
>>
>>
>> Case in point:
>>
>> http://www.sqlite.org/src/timeline?n=200
>>
>> Side note: is it me, or are the lines only showing up on the normal (n=20)
> timeline view? Perhaps the lines would just be too complicated? Using FF6.
200 entries wor
On Fri, Aug 26, 2011 at 1:30 PM, Richard Hipp wrote:
> It's been a long time since there has been an official release of Fossil.
> Probably I should do another soon
>
> To that end, I'm asking folks to please test the trunk. I use the trunk
> routinely, so it should be stable. But the more
On Fri, Aug 26, 2011 at 5:10 PM, Gé Weijers wrote:
>
> Recently the flag '-showfiles' was added to 'fossil timeline'. It shows
> which files were added, deleted or modified in each commit. The next release
> should contain this feature.
>
FWIW, the "showfiles" option has been available on the w
On Fri, 26 Aug 2011, Gilles wrote:
I'm not very clear at what a manifest is:
www.sqlite.org/debug1/doc/trunk/www/fileformat.wiki
It seems to be a list of artifacts (ie. changes?) for each file under
source control.
The manifest describes a committed revision. It's mostly file names and
ha
On Fri, 26 Aug 2011 16:27:50 -0400, Tomek Kott
wrote:
> To be honest I'm not either -- I don't use them personally. I believe it
>is used for auditing puproses, since it contains checksums of the files, the
>user, and timestamp.
I can live with that. Telling Fossil to stop watching a file is not
On Fri, Aug 26, 2011 at 4:29 PM, Tomek Kott wrote:
>
>> Case in point:
>>
>> http://www.sqlite.org/src/timeline?n=200
>>
>> Side note: is it me, or are the lines only showing up on the normal (n=20)
> timeline view? Perhaps the lines would just be too complicated? Using FF6.
>
That bug is here:
On Fri, Aug 26, 2011 at 10:32 PM, Sean McCleary wrote:
> 'A *property* is a name/value pair. Internally, fossil implements tags as
> properties with a NULL value. ... The *branch* tag tells (by its value)
> what branch the check-in is a member of. The default branch is called
> "trunk".'
>
> The "
On Fri, Aug 26, 2011 at 10:29 PM, Tomek Kott wrote:
> Side note: is it me, or are the lines only showing up on the normal (n=20)
>> timeline view? Perhaps the lines would just be too complicated? Using FF6.
>>
>
Works for me in Chrome, but yes an HTML canvas that size might annoy some
browsers.
Hi fossil user list,
I was reading the online documentation about branching and tagging, and
think I spotted a mistake. It looks like anonymous users don't have access
to change the wiki though, and I couldn't find a link to report mistakes or
something. Anyone know?
FYI, the mistake is:
'A *p
I have switched to the new "trunk" and I think it address the issue I had
with symlinks (sent in separate mail). Thanks!
The empty-dirs works as advertised but I have an enhancement request. If I
specify a multilevel directory and the upper levels do not exist the
directory is silently skipped. Ei
>
>
> Case in point:
>
> http://www.sqlite.org/src/timeline?n=200
>
> Side note: is it me, or are the lines only showing up on the normal (n=20)
timeline view? Perhaps the lines would just be too complicated? Using FF6.
Tomek
___
fossil-users mailing lis
> I'm not very clear at what a manifest is:
>
> To be honest I'm not either -- I don't use them personally. I believe it
is used for auditing puproses, since it contains checksums of the files, the
user, and timestamp.
www.sqlite.org/debug1/doc/trunk/www/fileformat.wiki
>
> It seems to be a list
On Fri, Aug 26, 2011 at 10:24 PM, Stephan Beal wrote:
> In the timeline view its unlikely that more than a few branches will be
> visible for any given timeframe unless the user expands the list to 200
> entries. But then the branch lines can be used to disambiguate.
>
Case in point:
http://www.
On Fri, Aug 26, 2011 at 9:38 PM, Joshua Paine wrote:
> I'm not arguing against the auto-coloring. I like it and I think it will
> be a real help. I do think that making similar names similar colors is
> an anti-goal or at least a non-goal.
But in fairness: the majority of the colors shown in the
On Fri, 26 Aug 2011 11:26:24 -0400, Tomek Kott
wrote:
>Do you mean a list of all files that have ever been deleted throughout the
>repository? Or a list of the files deleted in the last commit?
I meant the former: Checking out the latest revision of a file which
has at some point been deleted fro
I read a paper awhile back that talked about the minimum distance necessary
being 40 something, but I believe that eas in ciexyz colorspace.
On Aug 26, 2011 12:39 PM, "Joshua Paine" wrote:
> On 8/26/2011 3:11 PM, Martin Gagnon wrote:
>> It *could* be a feature, not a bug.. I mean.. if 2 branches h
On 8/26/2011 3:11 PM, Martin Gagnon wrote:
> It *could* be a feature, not a bug.. I mean.. if 2 branches have so
> similar name.. it might be wanted behavior to have very similar color...
If two branches have almost the same name, it's much more likely that I
actually meant them to be the same an
On Fri, Aug 26, 2011 at 9:14 PM, Stephan Beal wrote:
> On Fri, Aug 26, 2011 at 9:11 PM, Martin Gagnon wrote:
>
>> It *could* be a feature, not a bug.. I mean.. if 2 branches have so
>> similar name.. it might be wanted behavior to have very similar color...
>>
>
> LOL! That's a very interesting
On Fri, Aug 26, 2011 at 8:58 PM, Stephan Beal wrote:
> Updating now, and i'm using fossil heavily tonight, so i'll put it through
> my routine. (That said, my routine won't stress it all that much.)
>
For anyone skeptical about upgrading, i just upgraded all of my remote repos
and "the world is
On Fri, Aug 26, 2011 at 9:11 PM, Martin Gagnon wrote:
> It *could* be a feature, not a bug.. I mean.. if 2 branches have so similar
> name.. it might be wanted behavior to have very similar color...
>
LOL! That's a very interesting point.
--
- stephan beal
http://wanderinghorse.net/home/st
On Fri, Aug 26, 2011 at 3:04 PM, Joshua Paine wrote:
> > maybe there should be a "minimum distance" between color values? But we
> > can't know that without comparing against all existing values, which is
> > of course too much effort.
>
>
> I have no idea what the current algorithm is
>
40
On Fri, Aug 26, 2011 at 3:04 PM, Joshua Paine wrote:
> On 8/26/2011 2:58 PM, Stephan Beal wrote:
> > * branch-3.7.2 → #9abda6
> > * branch-3.7.4 → #99bca5
>
> These really are too close--only 1 away in each of RGB so that the first
> is just an indiscernible smidgen lighter than the second.
>
On 8/26/2011 2:58 PM, Stephan Beal wrote:
> * branch-3.7.2 → #9abda6
> * branch-3.7.4 → #99bca5
These really are too close--only 1 away in each of RGB so that the first
is just an indiscernible smidgen lighter than the second.
> maybe there should be a "minimum distance" between color values
On Fri, Aug 26, 2011 at 7:30 PM, Richard Hipp wrote:
> release to merge that branch into trunk. But "symlinks" and "trunk" are
> pretty close to one another, so active use of "symlinks" is nearly as good
> as active use of "trunk".
>
Updating now, and i'm using fossil heavily tonight, so i'll p
It's been a long time since there has been an official release of Fossil.
Probably I should do another soon
To that end, I'm asking folks to please test the trunk. I use the trunk
routinely, so it should be stable. But the more eyes the better.
I say I'm using the trunk - actually I'm curre
Do you mean a list of all files that have ever been deleted throughout the
repository? Or a list of the files deleted in the last commit?
I don't think there's a way to get the first. For the second, I would issue
first "fossil timeline" to get the id of the last commit ID, then issue
"fossil arti
On Fri, 26 Aug 2011 17:04:42 +0200, Gilles
wrote:
> How do I get the list of files that have been deleted?
It can be found through "fossil ui" > Branches > trunk, and clicking
on the artifact where the file was deleted.
Is there a CLI equivalent?
___
On Fri, 26 Aug 2011 18:23:18 +0400, Konstantin Khomoutov
wrote:
>Yes, it's possible to access all the versions up until the user ran
>"delete" -- that's how all VCSes work.
Thank you. How do I get the list of files that have been deleted?
"It can initially be confusing to see a file that's been
On Aug 26, 2011, at 4:51 PM, Konstantin Khomoutov wrote:
> That 67.18.92.124 address resolves to sqlite.org, so I wonder if it's
> possible to somehow contact spamhaus.org admins for this address to be
> removed--it seems unlikely that this domain was used to send spam.
It is not only possible,
On 08/25/11 20:39, Marty Backe wrote:
> If I want to see what files might change with an 'update', I supply the
> '-n' option. E.g. fossil update -n
>
> For files that have a merge conflict, the 'baseline', 'original', and
> 'merge' files get created on my local file system. All other files that
>
All messages I receive from this list since some time ago have the
"[SPAM]" tag in the subject, and the headers typically contain this:
X-Spam-Report: Spam Filtering performed by mx.sourceforge.net.
See http://spamassassin.org/tag/ for more details.
-0.0 SPF_HELO_PASS SPF: HELO matches
On Fri, 26 Aug 2011 15:39:42 +0200
Gilles wrote:
> I'm not clear about how "delete" works: It looks like it's a
> way to tell Fossil to stop versioning a given file, ie. the opposite
> of "add".
>
> The online help says that this command does not remove the files from
> the disk but... doe
> The online help says that this command does not remove the files from
> the disk but... does it remove it from the repo, or is it still
> possible to access all the versions up until the user ran "delete"?
>
> It only removes the file from the repo from the point of the "delete"
command on. So, a
Hello,
I'm not clear about how "delete" works: It looks like it's a way to
tell Fossil to stop versioning a given file, ie. the opposite of
"add".
The online help says that this command does not remove the files from
the disk but... does it remove it from the repo, or is it still
possible
I've made a bisect for on part of the problem. (for the "fossil: file
outside of checkout tree" error when doing "fossil diff etc/fstab" on the
exemple of my original post.
I found that before this change, it was working:
http://www.fossil-scm.org/index.html/fdiff?v1=d5c8419ca0c1887f&v2=04be4540a
44 matches
Mail list logo
