Thus said Matt Welland on Wed, 08 Apr 2015 22:39:36 -0700:
> > > Server says: ** WARNING: a fork has occurred **
> > > Server says: ** WARNING: a fork has occurred **
> >
> > I assume you actually had 2 forks in the content that you were
> > syncing?
> >
>
> One fork:
Can yo
On Wed, Apr 8, 2015 at 9:39 PM, Andy Bradford
wrote:
> Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
>
> > matt@xena:/tmp/testing$ fossil sync
> > Sync with file:///home/matt/fossils/blah.fossil
> > Round-trips: 1 Artifacts sent: 4 received: 0
> > Server says: ** WARNING: a fo
Thus said Matt Welland on Wed, 08 Apr 2015 21:07:00 -0700:
> matt@xena:/tmp/testing$ fossil sync
> Sync with file:///home/matt/fossils/blah.fossil
> Round-trips: 1 Artifacts sent: 4 received: 0
> Server says: ** WARNING: a fork has occurred **
> Server says: ** WARNING: a fork has o
On Wed, Apr 8, 2015 at 5:57 PM, Andy Bradford
wrote:
> Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:
>
> > What we are seeing is that forks happen due to simultaneous, partially
> > overlapping, commits and that neither party involved in the two
> > commits has any idea that a
Thus said Ron W on Wed, 08 Apr 2015 22:27:57 -0400:
> 2. The presence of such a tag will serve as a reminder that the fork
> exists.
If the goal is simply to make it easier to find forks, I don't think a
tag is necessary for that.
Fossil can already calculate the presence of forks, so may
On Wed, Apr 8, 2015 at 8:57 PM, Andy Bradford
wrote:
> Perhaps this will help:
>
> http://www.fossil-scm.org/index.html/info/6b410f914ef5be53
Thanks.
I would still like to see a special tag automatically added to a fork
commit when one is detected.
2 reasons:
1. If there is an intermediate r
Thus said Ron W on Wed, 08 Apr 2015 12:13:29 -0400:
> Ideally, this should never happen, but real working conditions might
> dictate making a commit during non-idea situations.
Right, specifically, offline checkins and situations where autosync is
entirely off.
I think in these cases it make
Thus said Matt Welland on Wed, 08 Apr 2015 08:27:00 -0700:
> What we are seeing is that forks happen due to simultaneous, partially
> overlapping, commits and that neither party involved in the two
> commits has any idea that a fork was committed.
Perhaps this will help:
http://www.fossil
What Scott says, abbreviated from the C FAQ:
http://c-faq.com/null/ptrtest.html
FWIW, I always use if(p) to verify a pointer is valid.
../Dave
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mai
Here is another problem with symlinks:
Last login: Tue Apr 7 20:11:50 on ttys004
: ~ ; cd /tmp
: /tmp ; fs init foo.fossil
project-id: d24564a4337e8c50f77a20ee355e2f76a9b84b78
server-id: aa025469a22046732337b7fa075c7c4e85f45c0a
admin-user: dmason (initial password is "d5a283")
: /tmp ; cd
On Wed, Apr 8, 2015 at 12:17 PM, Ron W wrote:
> On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison
> wrote:
>
>> Or whatever your team dictates. :)
>>
>
> In our case, we are required to follow "industry guidelines", except where
> compelling technical issues require a deviation. And such deviations
On Wed, Apr 8, 2015 at 1:58 PM, Scott Robison
wrote:
> Or whatever your team dictates. :)
>
In our case, we are required to follow "industry guidelines", except where
compelling technical issues require a deviation. And such deviations must
be documented. Also, use of NULL is considered more ind
On Wed, Apr 8, 2015 at 11:13 AM, Ron W wrote:
> FWIW, the coding rules I work under require us to write
> "if(pointer!=NULL)" because the invalid pointer is a compiler-dependent
> value.
>
> I've actually used a compiler where NULL was not 0. Instead it was
> 0x. Presumably this was parti
On Wed, Apr 8, 2015 at 12:25 PM, Andy Goth wrote:
> I hesitated to do much more than move existing code around since I don't
> know how strong the stylistic preferences are. For example, one thing I
> wanted to do was treat pointers as booleans, e.g. "if(pointer)" rather than
> "if(pointer!=0)",
On 4/8/15, Andy Goth wrote:
> On 4/8/2015 1:33 AM, bch wrote:
>> I don't know if it's just me, or if there's a school of thought
>> regarding this, but if this is a case of maintaining symlinks to publish
>> as part of a distribution, I usually relegate their management to a
>> script that will be
On Wed, Apr 8, 2015 at 6:55 AM, Martin Gagnon wrote:
> Fossil have a nice timeline graph that will show you
> the FORK clearly. And the CLI timeline command tell you that there's a
> FORK. (by adding *FORK* to the checkin entry):
I had not encountered this. Nor the "would fork" warning when doi
(email to reporter of problem several years ago, copying list so
discussion can continue here)
I made a fix to Fossil opening a repository containing symlinks. It's
currently on a branch. For details, see this thread:
http://www.mail-archive.com/fossil-users@lists.fossil-scm.org/msg20112.ht
On 4/8/2015 1:14 AM, Joe Mistachkin wrote:
I've made some tweaks on the branch.
Thank you, I appreciate it. I hesitated to do much more than move
existing code around since I don't know how strong the stylistic
preferences are. For example, one thing I wanted to do was treat
pointers as bo
On Wed, Apr 8, 2015 at 2:19 AM, Matt Welland wrote:
> A much better solution is to block a push that creates a fork and inform
> the user that they need to fix the fork and push again.
>
I disagree.
Automatic shunning of an incoming commit by the receiving repo is anathema
to Fossil's underlyin
On 4/8/2015 1:33 AM, bch wrote:
I don't know if it's just me, or if there's a school of thought
regarding this, but if this is a case of maintaining symlinks to publish
as part of a distribution, I usually relegate their management to a
script that will be part of a release generation process (wi
On Tue, Apr 7, 2015 at 10:14 PM, Andy Bradford
wrote:
> The software already warns users that a fork is imminent. They have the
> choice to ignore the warning, or not.
>
Even when auto-sync is enabled and the upstream repo can be contacted,
there is still a window where 2 (or more) commits can
On Wed, Apr 8, 2015 at 5:48 PM, wrote:
> I dislike JS as much as the next guy. However, I still feel that
> keeping the C simple makes the server cleaner and more auditable and the
> web UI more capable. I've only used Fossil for a week so far so take it
> for what it's worth, but it seems like
FWIW: The three Fossil self-hosting repositories stay in sync via a
cron job running on each server. See
https://www.fossil-scm.org/fossil/doc/trunk/www/selfhost.wiki for
additional information;.
On 4/8/15, Richard Hipp wrote:
> On 4/8/15, li...@ggp2.com wrote:
>> Is anyone interested in a dif
I have not looked at the source yet, but I think your explanation gives
me a clear picture of the issues this would involve. This would need
some sort of polling/persistent connection, and I'm not sure how well
that meshes with Fossil's current web implementation.
This is somewhat OT, but I've be
On Wed, Apr 8, 2015 at 5:24 PM, wrote:
> Thanks for the response, and sorry for bugging you :)
>
You're not bugging! i wish i could respond more fully to your posts, but my
left hand simply can't do it for the time being, and typing any notable
amount with only one hand is a real pain in the but
On Wed, Apr 8, 2015 at 6:16 AM, Richard Hipp wrote:
> On 4/8/15, Matt Welland wrote:
> > Today I got to hear from a team that had a very near serious QA escape
> due
> > to an undetected fork.
>
> Can you provide more detail on this incident so that I can better
> understand what Fossil can do t
On Wed, Apr 08, 2015 at 05:15:10PM +0200, Stephan Beal wrote:
> i'm (still) on medical leave with a disabled hand, so won't say more than:
> there are a couple old posts in the list archives explaining various
> pitfalls involved with autosync of ticket changes. Short form: it
> introduces all sort
On 4/8/15, li...@ggp2.com wrote:
> Is anyone interested in a diff with this functionality? I don't mind
> digging into the code, but I don't want to waste my time if it goes
> against a core idea of Fossil. I'd just like the option of using it
> with nothing external-facing other than SSH.
>
Th
On Wed, Apr 8, 2015 at 5:02 PM, wrote:
> Is anyone interested in a diff with this functionality? I don't mind
> digging into the code, but I don't want to waste my time if it goes
> against a core idea of Fossil. I'd just like the option of using it
> with nothing external-facing other than SSH
Is anyone interested in a diff with this functionality? I don't mind
digging into the code, but I don't want to waste my time if it goes
against a core idea of Fossil. I'd just like the option of using it
with nothing external-facing other than SSH.
On Sat, Apr 04, 2015 at 03:07:41PM +, li.
On 4/8/15, Matt Welland wrote:
> Today I got to hear from a team that had a very near serious QA escape due
> to an undetected fork.
Can you provide more detail on this incident so that I can better
understand what Fossil can do to help prevent a recurrence?
--
D. Richard Hipp
d...@sqlite.org
_
On Wed, Apr 08, 2015 at 06:55:17AM -0400, Martin Gagnon wrote:
> Sometimes, Fork are inevitable. User should understand the concept of a
> distributed SCM. Fossil have a nice timeline graph that will show you
> the FORK clearly.
Also: fossil leaves --bybranch
Joerg
___
On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
>On Tue, Apr 7, 2015 at 7:14 PM, Andy Bradford
><[1]amb-fos...@bradfords.org> wrote:
>
> Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:
> > If they can happen when two people push to central repos
On Tue, Apr 07, 2015 at 11:19:46PM -0700, Matt Welland wrote:
> Forks add little value but have a potentially high cost because they can be
> so confusing when they happen.
I completely disagree on this. Forks add a lot of value and getting
complains for every single action would be extremely anno
34 matches
Mail list logo
