Thanks for explaining this new feature. v1.33 showed a months old forgotten
commit and it was easy to merge and clean up. Wasn't sure how merging such
old changes would go.
Thanks for Fossil!
On Fri, May 29, 2015 at 10:24 PM, Doug Franklin nutdriverle...@comcast.net
wrote:
On 2015-05-29 19:19,
Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300:
Is my repo corrupt or what's wrong with the new (or the old) version?
Did you remember to make clean before building and optionally rerun
./configure?
Thanks,
Andy
--
TAI64 timestamp: 40005568acbb
I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib 1.2.8, loaded 1.2.8
SSL (OpenSSL 1.0.2a 19 Mar 2015)
Thus said to...@acm.org on Fri, 29 May 2015 20:57:16 +0300:
(1) 2015-05-29 17:48:57 [eba9fa6147] (current)
(2) 2014-11-05 13:36:22 [91ef16c613]
What artifacts are these? Fossil doesn't have them:
https://www.fossil-scm.org/index.html/info/eba9fa6147
Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300:
And, using --force does nothing, of course.
Actually, it does. Did you try to run ``fossil ci'' after running
``fossil merge --force'' to actually commit your changes?
There will be no files changed as part of the merge,
Thus said to...@acm.org on Sat, 30 May 2015 01:29:10 +0300:
As to what happened you probably guessed right. I must have used the
--branch option from within the 'mistake' branch. I was (until just
now) under the impression that the --branch option either starts a new
branch (if the name
On Fri, May 29, 2015 at 6:29 PM, to...@acm.org wrote:
As to what happened you probably guessed right. I must have used the
--branch option from within the 'mistake' branch. I was (until just now)
under the impression that the --branch option either starts a new branch
(if the name given is
On 2015-05-29 19:19, Ron W wrote:
I suspect, in most case, multiple independent branches with the same
name are not a problem. But trunk is a special case that may warrant a
warning.
I don't think I'd take that suspicion to the bank. Personally, I think
it should warn on duplication of an
9:24 PM
To: Fossil SCM user's discussion
Subject: Re: [fossil-users] WARNING: multiple open leaf check-ins on trunk:
On 5/29/15, to...@acm.org to...@acm.org wrote:
I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28
On 29 May 2015 at 10:57, to...@acm.org wrote:
Is my repo corrupt or what’s wrong with the new (or the old) version?
This is the new advisory system in 1.33:
https://www.fossil-scm.org/index.html/doc/trunk/www/changes.wiki
Improved fork detection on fossil update, fossil status and related
On 5/29/15, to...@acm.org to...@acm.org wrote:
I updated to this recent version of fossil:
This is fossil version 1.33 [282ae5e4de] 2015-05-28 17:05:13 UTC
Compiled on May 28 2015 21:56:18 using msc-18.00 (32-bit)
SQLite 3.8.10.2 2015-05-20 18:17:19 2ef4f3a5b1
Schema version 2015-01-24
zlib
Thus said to...@acm.org on Fri, 29 May 2015 22:18:00 +0300:
Check-in d137 was originally trunk but moved to a branch ``mistake.''
(I guess shunning would have been a better solution at the time, but
too late now, right?)
Actually, shunning was probably never a better solution for this kind
12 matches
Mail list logo
