On Tue, Oct 04, 2011 at 02:34:06PM -0700, Mike Meyer wrote:
> On Tue, Oct 4, 2011 at 1:50 PM, Erlis Vidal wrote:
>
> > You shun a commit or a file in a commit? Is in fossil the shun generating a
> > different commit?
> >
> > you can delete with git files that has history with
> >
> > git filter-b
On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
...
> Every time pragmatism loses to philosophy someone, somewhere, is gonna get
> screwed.
But "pragmatic" decisions made by someone who doesn't understand the
philosophy/principles/rules can also cause problems,
>
> It is noble to have a phi
On Tue, Oct 04, 2011 at 07:12:49PM -0400, Richard Hipp wrote:
> There is a fossil-dev mailing list now. I added it to this thread - to see
> if it actually works. Assuming the new mailing list does work, we should
> try to move these kinds of discussions there, to minimize the noise for
> people
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 10/05/2011 08:19 AM, Eric wrote:
> Not altogether a bad idea but, as you might expect, I would worry about how
> to select the time interval, and I think the system should insist on
> keeping a comment about the deletion.
Perhaps shuns should be p
Gé Weijers writes:
> On Mon, 3 Oct 2011, Konstantin Khomoutov wrote:
>> Is there no way to make it switchable at runtime (like via `fossil set
>> ipv6 on`) or is it doable but just complicated to implement?
>> Having a compile-time switch effectively doubles the number of binaries
>> one have to
Lluís Batlle i Rossell writes:
> On Mon, Oct 03, 2011 at 11:58:08AM -0700, Gé Weijers wrote:
>>
>>
>> On Mon, 3 Oct 2011, Lluís Batlle i Rossell wrote:
>>
>> >Additionally, I don't know how portable it is to use always getaddrinfo
>> >(POSIX-2001?) while requiring C89.
>>
>> C89 does not addres
Hello,
if I shun any contents from a repository, and rebuild... can I later 'unshun'
them, and then expect a 'pull' to get them from whatever repository containing
them?
Regards,
Lluís
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http
2011/10/5 Lluís Batlle i Rossell
> Hello,
>
> if I shun any contents from a repository, and rebuild... can I later
> 'unshun'
> them, and then expect a 'pull' to get them from whatever repository
> containing
> them?
>
I can't think of a reason why that wouldn't work.
--
D. Richard Hipp
d...@s
2011/10/5 Lluís Batlle i Rossell :
> On Tue, Oct 04, 2011 at 02:34:06PM -0700, Mike Meyer wrote:
>> On Tue, Oct 4, 2011 at 1:50 PM, Erlis Vidal wrote:
>>
>> > You shun a commit or a file in a commit? Is in fossil the shun generating a
>> > different commit?
>> >
>> > you can delete with git files
On 10/5/11 2:19 AM, Eric wrote:
On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
...
Every time pragmatism loses to philosophy someone, somewhere, is gonna get
screwed.
But "pragmatic" decisions made by someone who doesn't understand the
philosophy/principles/rules can also cause problems,
On Wed, Oct 5, 2011 at 12:19 AM, Eric wrote:
>
> On Wed, October 5, 2011 6:14 am, Matt Welland wrote:
> ...
> > Every time pragmatism loses to philosophy someone, somewhere, is gonna
> get
> > screwed.
>
> But "pragmatic" decisions made by someone who doesn't understand the
> philosophy/principle
On Wed, Oct 05, 2011 at 06:06:07PM +0200, Michal Suchanek wrote:
> 2011/10/5 Lluís Batlle i Rossell :
> > git looks to me as a tool for publishing development steps, not necessarily
> > very
> > related to the development history. The 'git version graph' is determined
> > by the
> > users the sam
On Tue, Oct 4, 2011 at 3:59 PM, Richard Hipp wrote:
> Fortunately, there was still one other copy in the undo stack
I would add a fourth lesson: Always backup your work.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fo
Thank you very much.
Based on your input, I used fossil remote-url to switch from port 443 to 80.
Now I can sync.
I will go back to port 443, when signed certificate will be available. I will
report then result then.
Thank you,
Jiri
--
Jiri Navratil
4. 10. 2011 v 20:24, Konstantin Khomoutov:
On Tue, 4 Oct 2011 15:14:56 +0200, Dmitry Chestnykh
wrote:
>I don't know a lot about Visual Studio, but*.sln looks to me like a solution
>file, don't ignore it.
>
>According to the git ignore template here
>https://github.com/github/gitignore/blob/master/VB.Net.gitignore,
>*.user and *.suo are s
On Wed, 5 Oct 2011 18:24:30 +0200
Lluís Batlle i Rossell wrote:
[...]
> > And when you find an issue with a commit that is some way back in
> > your personal branch it is more logical and easier to review your
> > branch if you append the fix to the commit where it belongs
> > logically or if you
Hi Ashish,
On Wed, 5 Oct 2011, Ashish SHUKLA wrote:
I wasn't aware of both sockaddr_storage, and getnameinfo(). They seem good to
me, and I've updated diff[1] to use them.
References:
[1] http://people.freebsd.org/~ashish/fossil-ipv6-rev-proxy.diff
A few comments (not all about your code):
On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> That sort of "we don't need it, we don't need it" mantra is a typical
> case of the famous "Blub paradox".
> I mean, if we have two DVCS tools one of which makes you able to
> rewrite history and anoth
On 5 October 2011 20:12, Mike Meyer wrote:
> On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> wrote:
>>
>> That sort of "we don't need it, we don't need it" mantra is a typical
>> case of the famous "Blub paradox".
>> I mean, if we have two DVCS tools one of which makes you able to
>> rewr
On Wed, 5 Oct 2011 11:12:31 -0700
Mike Meyer wrote:
> > That sort of "we don't need it, we don't need it" mantra is a
> > typical case of the famous "Blub paradox".
> > I mean, if we have two DVCS tools one of which makes you able to
> > rewrite history and another one which doesn't, the first on
On Wed, Oct 5, 2011 at 11:38 AM, Michal Suchanek wrote:
> On 5 October 2011 20:12, Mike Meyer wrote:
> > On Wed, Oct 5, 2011 at 10:56 AM, Konstantin Khomoutov
> > wrote:
> >>
> >> That sort of "we don't need it, we don't need it" mantra is a typical
> >> case of the famous "Blub paradox".
> >> I
I get the two points of view and I'm not saying one is right or wrong.
Modifying the history versus keeping everything as indeed happens (the
history after all)
Yesterday I was confused because I though the shun was done in the big file,
but indeed the shun was done in the commit also... will that
I had a file in my project that was no longer needed so I deleted the file
on my disk.
Next I did:
fossil delete ViewLogAll.php
fossil commit
The feedback showed (among others)
# DELETED ViewLogAll.php
Next I start the Fossil gui. Under 'Files' myfilename.txt is no longer shown
but when I pr
Here is the sequence of events.
A developer accidentally (and naively) checked in a file with no write
permissions.
On changing the file and checking it in others could not do an update and
would get something like this:
> fossil update
UPDATE foo.txt
fossil: unable to open file "/tmp/mrwellan/t
> A developer accidentally (and naively) checked in a file with no write
> permissions.
>
> On changing the file and checking it in others could not do an update and
> would get something like this:
>
> > fossil update
> UPDATE foo.txt
> fossil: unable to open file "/tmp/mrwellan/testing/test/f
My description was a bit off. The developer who initially checked in the
file without write permission is the one who cannot do the update. The
problem is not that fossil is storing or handling the perms wrong. The issue
is that a controlled file with no write permission causes fossil to barf on
an
On Wed, Oct 5, 2011 at 4:05 PM, Jos Groot Lipman wrote:
> **
> I had a file in my project that was no longer needed so I deleted the file
> on my disk.
>
> Only the original checkin is shown. There is no indication when or where
> the file was deleted. Should that not be in de file's history?
>
>
On Wed, 5 Oct 2011, Michal Suchanek wrote:
And when you find an issue with a commit that is some way back in your
personal branch it is more logical and easier to review your branch if
you append the fix to the commit where it belongs logically or if you
append it at the top of the history int
Hello
I'd like to use a fat GUI client instead of the CLI or the web UI, so
checked out GUI clients for Windows.
Since I can't stand Java, I didn't try jurassic-fossil.
Apparently, the only alternative for Windows is Ingo Koch's WinFossil.
http://repository.mobile-developers.de/cgi-bin/ikoch/sh
2011/10/5 Jiří Navrátil
> Thank you very much.
>
> Based on your input, I used fossil remote-url to switch from port 443 to
> 80. Now I can sync.
>
> I will go back to port 443, when signed certificate will be available. I
> will report then result then.
>
Please try it now and let me know how i
I'm back to port 443. I have to accept "Unknown SSL certificate". Sync is
working. Is Fingerprint all right? Accept always not save me before the same
questions. I have to find, how to avoid this "WARNING: Certificate doesn't
match the saved certificate for this host!" probably.
Thank you,
Jiri
I upgraded to
This is fossil version 1.19 [080d27a6b2] 2011-10-05 08:00:00 UTC
Not sure, what I shall do in gdb. So I have this. Please let me know, what next
I can trace. Sorry
fossil(2681) malloc: *** mmap(size=18446744067267100672) failed (error code=12)
*** error: can't allocate region
**
Indeed, with 1.19 the problem is solved after a rebuild. Thanks.
Jos
_
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: donderdag 6 oktober 2011 2:38
To: fossil-users@lists.fossil-scm.org
Subject: Re: [fos
33 matches
Mail list logo
