Hello
I delete a file with Windows Explorer that was part of the repository
and had been checked out.
Now, when I run "fossil commit", I get the following error message:
=
D:\>fossil commit
C:\fossil.exe: missing file: a8711407.txt
C:\fossil.exe: aborting due to prior errors
It is more like a logical process. You want to work on something, create a
branch, work on it and commit. If you have to create a branch when committing,
you will have to remember if this is first commit in that branch or subsequent.
You commandline will also be different for first commit that c
So I wanted to use javadoc/scaladoc style documentation and take advantage of
fossils embedded documentation -- I put the scaladoc under /docco and
happily was going to http://server:port/repo/doc/trunk/docco/index.html - but
there noscript was already waiting for me, saying "No, no!". I couldn'
On Tue, 9 Aug 2011, Richard Hipp wrote:
On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers wrote:
If you create the branch first you cannot forget later and commit to the wrong
branch.
I beg to differ! Just this past Friday, I did three separate commits to SQLite
that went into the wrong
branc
I stumbled over this while I had a network outage...
$ until fossil configuration pull all && fossil sync ; do echo; echo; date;
echo; echo; sleep 5 ; done
Bytes Cards Artifacts Deltas
Sent: 58 1 0 0
fossil: cannot connect to hos
On Tue, 9 Aug 2011, Lluís Batlle i Rossell wrote:
If you could just tell fossil that you intend to commit to a new
branch from the current workspace/checkout creating that extra
commit object could be avoided without risking a commit to the wrong
branch.
You can *later* change the branch, af
On Tue, Aug 9, 2011 at 2:33 PM, Gé Weijers wrote:
>
> If you create the branch first you cannot forget later and commit to the
> wrong branch.
I beg to differ! Just this past Friday, I did three separate commits to
SQLite that went into the wrong branch even though the correct branch
already
On Tue, Aug 09, 2011 at 11:33:19AM -0700, Gé Weijers wrote:
>
>
> On Tue, 9 Aug 2011, Richard Hipp wrote:
>
> >Change the subject: Please help me to understand why people want to create
> >a new branch before adding
> >changes to that branch, rather than just waiting until they check-in their
On Tue, 9 Aug 2011, Richard Hipp wrote:
Change the subject: Please help me to understand why people want to create a
new branch before adding
changes to that branch, rather than just waiting until they check-in their
edits? I'm not being
sarcastic or critical here. A lot of people do this
On Tue, Aug 09, 2011 at 02:04:36PM -0400, Brian Cottingham wrote:
> Is there a way to do in from the command line?
There is not much of any commit editing in the command line, for what I know.
But at commit time you have '-b'. So using the ui for those corner cases is not
a big trouble for me at
Is there a way to do in from the command line?
2011/8/9 Lluís Batlle i Rossell
> On Tue, Aug 09, 2011 at 01:01:55PM -0500, tpero...@compumation.com wrote:
> > So, how do you move commits in the trunk to a new branch after the fact.
>
> Open the UI, click the checkin, then edit... and check the
On Tue, Aug 09, 2011 at 01:01:55PM -0500, tpero...@compumation.com wrote:
> So, how do you move commits in the trunk to a new branch after the fact.
Open the UI, click the checkin, then edit... and check the part about "starts a
new
branch".
Regards,
Lluís.
> -Original Message-
> From:
So, how do you move commits in the trunk to a new branch after the fact.
Thanks,
Tony Perovic
-Original Message-
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Joshua Paine
Sent: Tuesday, August 09, 2011 10:10 AM
To: fossil
Because the Chapter 4.4 in the Fossil Version Control / Users Guide Version 1.7
by Jim Schimpf does it that way.
From: fossil-users-boun...@lists.fossil-scm.org
[mailto:fossil-users-boun...@lists.fossil-scm.org] On Behalf Of Richard Hipp
Sent: Tuesday, August 09, 2011 9:58 AM
To: fossil-users@li
On Tue, Aug 9, 2011 at 8:35 AM, Konstantin Khomoutov <
flatw...@users.sourceforge.net> wrote:
> On Tue, 9 Aug 2011 08:19:46 -0700
> Matt Welland wrote:
>
> > I often am planning a change or thinking ahead and will create the
> > branch to record my intentions before I've started coding. I do like
On 9 Aug 2011, at 18:15, Matt Welland wrote:
>
> **soapbox mode - feel free to stop reading :) **
>
> The list of things that chip away at making a case for using fossil in
> serious work (lots of geographically distributed developers with minimal
> communication channels and a complex project
On Tue, Aug 9, 2011 at 9:25 AM, Ron Wilson wrote:
> On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp wrote:
> > The way I've *always* done things is:
> >
> > (1) ... edit files
> > (2) fossil commit -branch new-branch
> >
> > But I see many people want to do a 4-step process:
> >
> >
On Tue, Aug 9, 2011 at 10:58 AM, Richard Hipp wrote:
> The way I've *always* done things is:
>
> (1) ... edit files
> (2) fossil commit -branch new-branch
>
> But I see many people want to do a 4-step process:
>
> (1) fossil branch new new-branch
> (2) fossil update new-branch
I agree with the others, I usually start a branch as a part of the process
of working on some new feature. It just feels more organized than
remembering to decide what branch to use when I finally commit, or changing
the branch after the fact.
2011/8/9 Lluís Batlle i Rossell
> On Tue, Aug 09, 2
On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote:
> On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com <
> tpero...@compumation.com> wrote:
> (1) fossil branch new new-branch
I forgot to add that I don't like this approach *also* because it does not let
me type teh message
On Tue, Aug 09, 2011 at 11:27:09AM -0400, Joshua Paine wrote:
> On 8/9/2011 11:19 AM, Matt Welland wrote:
> > Note: It is annoying to me that "fossil branch new foo" won't simply
> > branch from the current node.
>
> +1
>
> > By the way, how does "update" differ from "co" in your step 2 below?
>
On Tue, Aug 09, 2011 at 11:06:23PM +0800, Ambrose Bonnaire-Sergeant wrote:
> Personally, this is a habit I bring from git, mainly because I'm not aware
> of any other way to doing things.
>
> I was not aware of fossil commit -branch new-branch, seems like a much
> better alternative.
>
> Half the
On Tue, 9 Aug 2011 08:19:46 -0700
Matt Welland wrote:
> I often am planning a change or thinking ahead and will create the
> branch to record my intentions before I've started coding. I do like
> the ability to checkin changes to a branch but would generally not
> intentionally use it out of the
On Tue, Aug 09, 2011 at 10:58:02AM -0400, Richard Hipp wrote:
> On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com <
> tpero...@compumation.com> wrote:
> Change the subject: Please help me to understand why people want to create
> a new branch before adding changes to that branch, rather th
On Tue, 9 Aug 2011 17:04:04 +0200
Gour-Gadadhara Dasa wrote:
> > Please help me to understand why people want to
> > create a new branch before adding changes to that branch, rather
> > than just waiting until they check-in their edits? I'm not being
> > sarcastic or critical here. A lot of peop
On Tue, Aug 9, 2011 at 4:58 PM, Richard Hipp wrote:
> That seems like so much more trouble. What am I missing? Is it that
> people are unaware that they can make edits that are destined to go into a
> branch before that branch actually
>
In my experience it's that when i know i've reached a br
On 8/9/2011 11:19 AM, Matt Welland wrote:
> Note: It is annoying to me that "fossil branch new foo" won't simply
> branch from the current node.
+1
> By the way, how does "update" differ from "co" in your step 2 below?
If you have no edited files, they have the same effect. But if you have
some
I often am planning a change or thinking ahead and will create the branch to
record my intentions before I've started coding. I do like the ability to
checkin changes to a branch but would generally not intentionally use it out
of the risk of forgetting that my changes are intended for a branch and
On 8/9/2011 11:04 AM, Gour-Gadadhara Dasa wrote:
> Maybe the way how other DVCS work?
> Which DVCS can create branch along with the commit?
I was thinking it was possible and I had done it in git, but I don't
remember how or see it in the documentation, so I think I was mistaken.
--
Joshua Pain
On 8/9/2011 10:58 AM, Richard Hipp wrote:
> Change the subject: Please help me to understand why people want to
> create a new branch before adding changes to that branch, rather than
> just waiting until they check-in their edits?
In SVN (and possibly others), you have to create the branch first
On 08/09/2011 02:16 PM, Richard Hipp wrote:
> da39a3ee5e6b4b0d3255bfef95601890afd80709 is the hash for a zero-length
> object. Something is clearly messed up.
As a general rule of thumb, whenever mysteriously zero-length files crop
up, the first thing I check is whether anything's run out of dis
Personally, this is a habit I bring from git, mainly because I'm not aware
of any other way to doing things.
I was not aware of fossil commit -branch new-branch, seems like a much
better alternative.
Half the time I start hacking on something, then "oh, darn I should have
started a branch before
On Tue, 9 Aug 2011 10:58:02 -0400
Richard Hipp wrote:
> Please help me to understand why people want to
> create a new branch before adding changes to that branch, rather than
> just waiting until they check-in their edits? I'm not being
> sarcastic or critical here. A lot of people do this and
On Tue, Aug 9, 2011 at 10:28 AM, tpero...@compumation.com <
tpero...@compumation.com> wrote:
>
>
> fossil branch new Test 5947928ba
>
>
>
>
>
Change the subject: Please help me to understand why people want to create
a new branch before adding changes to that branch, rather than just waiting
It appears that clearsign wasn't set (blank).
fossil set clearsign
clearsign
The default is OFF, right? Just to be sure:
fossil set clearsign 0
fossil set clearsign
clearsign (local) 0
Still getting:
fossil branch new Test 5947928b
On Tue, Aug 9, 2011 at 9:05 AM, Marco Maggesi wrote:
> Thank you for your quick answer.
>
> I run test-integrity and I found that both repositories are corrupted.
> One says:
>
> fossil: checksum mismatch on blob rid=58:
> da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
> 01f57728b3a5d55520becb489146d
Hi,
I found another copy of the same repository which is up to date and
doesn't have this inconsistency.
This solves my current problem.
BTW, these repositories are quite small (~120K).
If you think that they can be useful for debugging, I can send them to you.
Thank you for your support,
Marco
Thank you for your quick answer.
I run test-integrity and I found that both repositories are corrupted.
One says:
fossil: checksum mismatch on blob rid=58:
da39a3ee5e6b4b0d3255bfef95601890afd80709 vs
01f57728b3a5d55520becb489146d0a7f42f9638
The other says:
skip phantom 177 ccc986b41c2a37fb86a82
On Tue, Aug 9, 2011 at 8:25 AM, Marco Maggesi wrote:
> Hello,
>
> I have two fossil repositories (the "local" one and the "remote" one) and I
> get the following error when I try to pull:
> "content does not mach sha1 hash"
>
> So, first of all, I would like to establish if one or both repositori
Hello,
I have two fossil repositories (the "local" one and the "remote" one) and I get
the following error when I try to pull:
"content does not mach sha1 hash"
So, first of all, I would like to establish if one or both repositories are
corrupted.
Are there specific commands to check the integ
40 matches
Mail list logo
