is a
recommended practice around here.
Cheers.
P.S: Apparently, the command line timeline also joins all the message
into a single line. I still have to look through the code to see if
it's done at commit/import time or just at rendering.
--
Isaac Jurado
"The noblest pleasure i
te-space: pre;
}
Reference:
http://stackoverflow.com/a/9753612/1100958
Regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http:
g. In your version,
I guess you could try with the ".timelineTableCell" class, although that
will change more than you expect.
Regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding."
records, use --full-tree");
}else
Then I tried commenting the call to fossil_fatal() and the import
completed, but the old files were not removed.
So, finally, my question is. What is that code lacking in order to
correctly import copy and rename information?
Regards.
--
provide better repository compression. I have special interest, even a
bit irrational I must admit, in testing how Fossil's repository size
responds to renames as I tend to reorganize code quite often. Specially
since Mercurial suffers a bit dramatically in most cases.
Thanks for your t
commit nodes/boxes:
cursor: pointer
That way people would get a hint that the box is clickable.
For other features, I guess there should be more mentions to the release
notes. Other projects do that.
Cheers.
--
Isaac Jurado
"The noblest
even if there already exists one or more other
> branches with the same name. At
> http://www.fossil-scm.org/fossil/timeline?n=200&r=experimental it
> looks like there are a dozen or more "experimental" branches currently
> in the Fossil tree.
That is very interesting
El 29/05/2013 06:28, "Jonathan Otsuka" escribió:
>
> Downloads are not compiled with --markdown (its still experimental) you
will need to checkout and compile fossil with --markdown yourself.
Beware that --mardown is not a configure option anymore, in trunk, so it
will be enabled by default in fu
Replying Richard Hipp:
> On Mon, May 27, 2013 at 3:35 PM, Isaac Jurado wrote:
>
>> Hello,
>>
>> I'm testing Fossil by migrating a bunch of Mercurial repositories.
>> Unlike Git, Mercurial tracks file renames. However, in order to create
>> a Fossil
ame = fossil_strdup(zTo);
+pFile->isFrom = 0;
}
- fossil_fatal("cannot handle R records, use --full-tree");
}else
if( memcmp(zLine, "deleteall", 9)==0 ){
gg.fromLoaded = 1;
}else
if( memcmp(zLine, "N ", 2)==0 ){
related. Maybe a verbose compilation (showing all
compiler and linker flags) could reveal a hint. But I may also be
wrong, as I'm extrapolating from what I know about ELF binaries, so in
Mach'O may not apply.
Regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understand
** The XMARK table provides a mapping from fast-import "marks" and symbols
However, it doesn't seem to make much difference. Is there any other
SQLite tunable that can improve performance even at the cost of
resistance to hardware failure?
Thanks in adv
looks like they were added after artifact
delta compression. Which actually seems even more confusing.
Best regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding."
Leonardo da Vinci
___
On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger
wrote:
> On Mon, Jul 01, 2013 at 12:08:42AM +0200, Isaac Jurado wrote:
>> After the results, the conclusion is obvious: the generic artifact delta
>> compression is outperforming the delta manifest convention.
>>
>>
On Mon, Jul 1, 2013 at 9:44 PM, Joerg Sonnenberger
wrote:
> On Mon, Jul 01, 2013 at 05:18:40PM +0200, Isaac Jurado wrote:
>> On Mon, Jul 1, 2013 at 4:52 PM, Joerg Sonnenberger
>> > Delta manifests are not meant to reduce the repository size, but the
>> > amount of par
El 12/07/2013 00:28, "Aaron W.Hsu" escribió:
>
> I have a Git fast-export that comes in at around 322MB in size or
thereabouts. I am running the Windows version of Fossil from 2013-06. I run
the following from within PowerShell and get some funny output:
>
> C:\...> git fast-export --all | fossil
El 11/07/2013 17:52, "Trachta, Nathan [USA]"
escribió:
>
> Hi,
>
>
>
> I’m looking at using Fossil as a CM tool. Because of our systems I’m
looking at having a stand-alone Fossil repository with remote users who
need to have access to clones of the repository. This means the remote
users will be
commits and manifest artifacts is not
currently saved anywhere. I don't think it should be too much difficult
to do though, because every other version control system does it.
If you have some patience, I may take a look at it once I finish testing
my import patches
El 18/07/2013 20:53, "Aaron W.Hsu" escribió:
>
> [snip]
>
> I hope this helps! I am not sure which line contributes to the failed
import.
I forgot to ask earlier but, do you have non-latin filenames or some
textual content.
I'm asking because git generates octal escaped sequences (\154) for
non-
(i.e. the whole contents of that particular version of your
Makefile) and calculate its size in bytes. If I'm correct the size
of the Makefile content should approximately match:
content_size = reported_size + linecount_in_content
Once this behaviour is confirmed, the next
st-class support in almost any computer
language, bindings would not be necessary and the current process model
could be kept.
Best regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossi
On Mon, Jul 22, 2013 at 1:04 PM, Isaac Jurado wrote:
>
> - Ensuring API/ABI compatibility is harder. And this actually slows
> down development because new features have to be implemented
Sorry, incomplete sentence:
New features would have to be implemented in the library
a small and concrete set of users? That code will
need maintenance too, and a compatibility compromise if often necessary
for practical reasons.
Regards.
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
'.1' to the repo ticket number,
Like this?
Origin: 1
Clone Origin to A: 1.1
Clone Origin to B: 1.2
Clone A to C: 1.1.1
Clone A to D: 1.1.2
Clone B to E: 1.2.1
Clone B to F: 1.2.2
A creates ticket: 1.1.1
B creates ticket: 1.2.1
Regards.
--
Isaac Jurado
"The noblest pleasur
(not essential, but nice).
That looks like a Fossil to Fossil export/import feature, without having
to go through Git fast-export format, right?
--
Isaac Jurado
"The noblest pleasure is the joy of understanding"
Leonardo da Vinci
___
fossi
age and abort.
*/
void login_verify_csrf_secret(void){
if( g.okCsrf ) return;
if( fossil_strcmp(P("csrf"), g.zCsrfToken)==0 ){
g.okCsrf = 1;
return;
}
fossil_fatal("Cross-site request forgery attempt");
}
Regar
src/shun.c
==
--- src/shun.c
+++ src/shun.c
@@ -133,20 +133,21 @@
@
@
@
@
@
+ @
@ Enter the UUID of a previous shunned artifact to cause it to be
@ accepted again in the repository. The artifact content is not
@ restored because the content is u
Replying Isaac Jurado:
>
> Index: src/info.c
> ==
> --- src/info.c
> +++ src/info.c
> @@ -1427,11 +1427,11 @@
>if( !g.perm.Read ){ login_needed(); return; }
>if( rid==0 ) fossil_redirect_home(
imes now, but with Mercurial. As I said, I would expect
Fossil to work the same in this workflow because it is a very simple
one: no criss-cross merges, no cherrypicking and the resulting history
is beautifully clean.
I hope it helps. Best regards.
--
Isaac Jurado
"The noblest pleasure is t
reasons of why there typical
"log" command is called "timeline" in Fossil; and also why hiding the
possibility of altering the commit time, because it would lead to a
confusing timeline graph.
When I converted an Hg repo that had its history reordered (with "hg
h
El 09/08/2013 14:18, "Richard Hipp" escribió:
>
>
>
> On Fri, Aug 9, 2013 at 7:40 AM, Isaac Jurado wrote:
>>
>> As I understand it, in Fossil, the history is mostly driven by the date
>> and time of the events, whereas in Git and Hg ancestry relationshi
it.
Delta manifests are quite interesting because they follow the same
design concepts as Mercurial's delta storage. I have already
mentioned it, but I have a Fossil branch that can generate delta
manifests on import. However, I still don't have any place to publish
it.
Re
On Sun, Aug 18, 2013 at 1:59 PM, Stephan Beal wrote:
> On Sun, Aug 18, 2013 at 10:53 AM, Isaac Jurado wrote:
>>
>> It's about backwards compatibility. Fossil will not generate delta
>> manifest on commit unless there already are delta manifest on the
>> repositor
minutes to be imported. I
previously tried importing the glibc repository in a machine with 16GB
of RAM but, after a couple of hours, I interrumped the process.
So if any of you is considering importing the Linux kernel repository as
a test, think twice.
Best regards.
--
Isaac Jurado
"The no
34 matches
Mail list logo
