On Tue, Oct 28, 2014 at 5:39 PM, Baruch Burstein
wrote:
>
> On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp wrote:
>
>> Just be VERY CAREFUL that you don't add an artifact that is also used in
>> some other check-out that you want to keep, because after you shun it will
>> be gone forever.
>>
>
>
On Tue, Oct 28, 2014 at 7:21 PM, wrote:
> could this file syncing also work with FTP
>
No. There needs to be a process that understands the Fossil repository on
both ends. That does not exist on the remote side in the case of FTP.
It works for http: and https: because the remote side process
I tried it and it works very well. Thanks. So, I guess I can leave all repos
open all the time at both locations, and only do PULL/SYNC/PUSH at start/end of
work day.
(I only worry a bit about the possibility of the USB eventually becoming full
during a ‘push’ what consequences will it have on
Actually you might. By pushing a new tip on a branch a modified file X
will likely cause the previous version of X to change to delta storage
based on the new commit.
IIRC.
On Tue, Oct 28, 2014 at 2:46 PM, B Harder wrote:
> On 10/28/14, Baruch Burstein wrote:
>> On Tue, Oct 28, 2014 at 11:25 PM
On 10/28/14, Baruch Burstein wrote:
> On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp wrote:
>
>> Just be VERY CAREFUL that you don't add an artifact that is also used in
>> some other check-out that you want to keep, because after you shun it
>> will
>> be gone forever.
>>
>
> Shouldn't the shunn
On Tue, Oct 28, 2014 at 11:17 PM, Ron W wrote:
> Maybe could be as simple as adding the relevant artifact IDs to the shun
> list and rebuilding. (Though that would be rather slow (which is not
> necessarily a bad thing for this feature)).
>
See this commit (
http://fossil-scm.org/index.html/info
On 10/28/14, Richard Hipp wrote:
> On Tue, Oct 28, 2014 at 5:17 PM, Ron W wrote:
>
>> Maybe could be as simple as adding the relevant artifact IDs to the shun
>> list and rebuilding. (Though that would be rather slow (which is not
>> necessarily a bad thing for this feature)).
>>
>>
> Yep. Just
On Tue, Oct 28, 2014 at 11:25 PM, Richard Hipp wrote:
> Just be VERY CAREFUL that you don't add an artifact that is also used in
> some other check-out that you want to keep, because after you shun it will
> be gone forever.
>
Shouldn't the shunning function/command take care of rebasing any del
On Tue, Oct 28, 2014 at 5:17 PM, Ron W wrote:
> Maybe could be as simple as adding the relevant artifact IDs to the shun
> list and rebuilding. (Though that would be rather slow (which is not
> necessarily a bad thing for this feature)).
>
>
Yep. Just be VERY CAREFUL that you don't add an artifa
On Tue, Oct 28, 2014 at 3:11 PM, B Harder wrote:
> Not a bad idea -- this part of the description:
> < itself) are removed from the repository whenever the repository is
> reconstructed using the "rebuild" command.>>
>
> may roughly be what we're looking for.
Maybe could be as simple as adding
Not a bad idea -- this part of the description:
<>
may roughly be what we're looking for. We happen to be applying to a
specific artifact only (tip of branch) which shouldn't be any worse
than shunning in the middle of a branch, and may be simpler (barring
the fact that a tip will have to be prope
On Tue, Oct 28, 2014 at 2:21 PM, Stephan Beal wrote:
> On Tue, Oct 28, 2014 at 7:14 PM, B Harder wrote:
>>
>> 3) I can't think of anything else...
>>
>
> You will.
>
Perhaps looking at how shunning works would help
___
fossil-users mailing list
fossil
On Tue, Oct 28, 2014 at 7:31 PM, B Harder wrote:
> That said -- I would like an option to "pop and discard" from a branch
> tip. Possible? If the repo has been sync'd, then that work would come
> back to you on next sync (that's understood), but if it hasn't been
> sync'd, it could be useful.
>
On Tue, Oct 28, 2014 at 7:14 PM, B Harder wrote:
> 1) how complex is the structure/relation that needs to be popped to do
> the operation as cleanly as possible
>
On the surface it's really simple because we're guaranteed that there are
no references to the top-most item. The details Richard men
That's pretty much what I figured... I'll have to dig in and
understand cards (and maybe "sit down" again w/ you and just generally
chat) -- but I expect to see a linear relationship. My intuition tells
me one ought to be able to pop-and-delete back to "origin" -- of
*course* if a repo has been rep
On Tue, Oct 28, 2014 at 7:05 PM, B Harder wrote:
> Are references "backward", "forward", or both ? What I mean is,
> roughly, is fossil a doubly linked list, or singly, and if single,
> what direction?
>
In this case it's like a stack and you could only delete from the top (and
then the next top
(copy/paste sbeal response in diff't thread)
> i looked into that sometime in the past year. In theory, once you can pop the
> top-most
> commit, you can pop any number (but always from the top). But the devil's in
> the details -
> getting each and every cross-reference and delta removed/replace
On Tue, Oct 28, 2014 at 1:31 PM, B Harder wrote:
> I would like an option to "pop and discard" from a branch
> tip. Possible? If the repo has been sync'd, then that work would come
> back to you on next sync (that's understood), but if it hasn't been
> sync'd, it could be useful.
>
To do an "un
On Tue, Oct 28, 2014 at 6:31 PM, B Harder wrote:
> That said -- I would like an option to "pop and discard" from a branch
> tip. Possible? If the repo has been sync'd, then that work would come
> back to you on next sync (that's understood), but if it hasn't been
> sync'd, it could be useful.
>
On 10/28/14, Jungle Boogie wrote:
> Dear Richard,
>
> From: Richard Hipp
> Sent: Tue, 28 Oct 2014 10:09:25 -0400
> To: Fossil SCM user's discussion
> Subject: Re: [fossil-users] Fossil checksum
> >
>> On Tue, Oct 28, 2014 at 10:00 AM, Stephan Beal
On Tue, Oct 28, 2014 at 1:10 PM, Jungle Boogie
wrote:
> Is there a way to delete the commits and any traces of it?
>
https://www.fossil-scm.org/fossil/doc/trunk/www/shunning.wiki
--
D. Richard Hipp
d...@sqlite.org
___
fossil-users mailing list
fossi
Dear Richard,
From: Richard Hipp
Sent: Tue, 28 Oct 2014 10:09:25 -0400
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] Fossil checksum
>
On Tue, Oct 28, 2014 at 10:00 AM, Stephan Beal
wrote:
i don't remember any numbers from that thr
On Tue, Oct 28, 2014 at 3:51 PM, Gour wrote:
> On Tue, 28 Oct 2014 10:09:25 -0400
> Richard Hipp wrote:
>
> > That same commit rate will cause Fossil to exceed its maximum
> > repository size (140 terabytes) in about four minutes.
>
> What now?
>
At that point we would ask the owners of that db
On Tue, 28 Oct 2014 10:09:25 -0400
Richard Hipp wrote:
> That same commit rate will cause Fossil to exceed its maximum
> repository size (140 terabytes) in about four minutes.
What now?
Sincerely,
Gour
--
The spirit soul bewildered by the influence of false ego thinks
himself the doer of ac
On Tue, Oct 28, 2014 at 10:00 AM, Stephan Beal
wrote:
> i don't remember any numbers from that thread, but do remember one quote.
> When (whoever it was, probably Richard) explained that The Math shows that
> a collision is not likely to happen until some tens of thousands of years
> in the futur
On Tue, Oct 28, 2014 at 2:42 PM, Baruch Burstein
wrote:
> If it is sha1, are there plans to switch to sha256?
>
>
> I am not an authority on fossil roadmap, but I would guess that there is
> no such plan. Why switch? the hashes are not used for security, but as a
> type of checksum. The chance of
On Tue, Oct 28, 2014 at 1:24 PM, Martin Gagnon wrote:
> -#undef FLC
> +#undef FLCA
>
Thank you! Probably harmless but nonetheless fixed.
--
- stephan beal
http://wanderinghorse.net/home/stephan/
http://gplus.to/sgbeal
"Freedom is sloppy. But since tyranny's the only guaranteed byproduct of
On Tue, Oct 28, 2014 at 3:09 PM, Jungle Boogie
wrote:
> From what I've read regarding the fossil documentation, it seems that sha1
> hashes are used for the files. Is that still correct?
>
Yes
> If it is sha1, are there plans to switch to sha256?
I am not an authority on fossil roadmap, but
Hello All,
From what I've read regarding the fossil documentation, it seems that sha1
hashes are used for the files. Is that still correct?
If it is sha1, are there plans to switch to sha256?
Thanks!
--
inum: 883510009027723
sip: jungleboo...@sip2sip.info
xmpp: jungle-boo...@jit.si
__
Being there, I just found by chance a typo which is probably harmless on
libfossil..
(diff against: 61233f6026)
Index: src/fsl.c
==
--- src/fsl.c
+++ src/fsl.c
@@ -107,11 +107,11 @@
return NULL;
}else{
/* realloc() */
On Tue, Oct 28, 2014 at 12:42 PM, Richard Hipp wrote:
> When the merge from trunk into dave occurred (check-in c2d7402366) there
> were merge conflicts on the fsl_cx.c file. (You can see this by doing
> "fossil up 81f67b; fossil merge 6c18a25;") These merge conflicts were
> manually resolved, a
On Tue, Oct 28, 2014 at 5:27 AM, Stephan Beal wrote:
>
>
> During that time Dave merged trunk into his branch and everything is
> great. He then makes one more commit to his branch before trying to merge
> his branch to the trunk. He noticed, however, that while there were no
> conflicts, several
Hi, all,
Dave noticed a weird thing today while trying to do what appeared to be a
routine merge...
here's the timeline of reference:
http://fossil.wanderinghorse.net/repos/libfossil/index.cgi/timeline?c=2014-10-27
During that time Dave merged trunk into his branch and everything is great.
He t
33 matches
Mail list logo
