On Mon, Apr 6, 2015 at 3:48 PM, Matt Welland mattrwell...@gmail.com wrote:
On Mon, Apr 6, 2015 at 10:05 AM, James Moger james.mo...@gmail.com
wrote:
By default non-fast-forward pushes (fork in Fossil terms) are blocked.
This is what I thought. So what technical obstacles are there
W dniu 07.04.2015 o 18:03, Ron W pisze:
I don't think they should be blocked, but the upstream repo should
detect them and warn about them.
If they can happen when two people push to central repository one after
another, then IMHO they should be blocked. Or at least there should be a
possibility
Now I get it. Thanks for summing up your stance.
Pozdrawiam / With best regards,
Orzech
W dniu 07.04.2015 o 20:17, Ron W pisze:
I am saying warn. The louder the better.
Naturally, when (a) auto-sync is enabled, and (b) you have
connectivity with your upstream, then it is POSSIBLE for the
Thus said Ron W on Mon, 06 Apr 2015 15:18:56 -0400:
Auto-sync helps to avoid forks. But the best way to avoid forks is
good communication between contributors. Still, I would like to see
the ability to generate a warning when a Fossil server receives a
commit against a parent that
Thus said Piotr Orzechowski on Tue, 07 Apr 2015 19:46:22 +0200:
If they can happen when two people push to central repository one
after another, then IMHO they should be blocked. Or at least there
should be a possibility to enable/disable some kind of lock mechanism.
I wonder just
My naïve user expectation is checking in .fossil-settings/allow-symlinks
with contents 1 is all I need to do to get symlinks to work in a
Fossil repository. It does make it possible to check in symlinks.
However, it doesn't help when opening a new checkout. In this
situation, symlinks are
On 4/8/2015 12:15 AM, Andy Goth wrote:
My naïve user expectation is checking in .fossil-settings/allow-symlinks
with contents 1 is all I need to do to get symlinks to work in a
Fossil repository. It does make it possible to check in symlinks.
However, it doesn't help when opening a new
The function sterilize_manifest() in manifest.c has me puzzled. It adds
a line of junk to the end of a manifest to create a file that can't be
interpreted as a control artifact if checked into another repository.
My question is whether or not this can ever actually be a problem, or if
this
On 4/7/15, Andy Goth andrew.m.g...@gmail.com wrote:
The function sterilize_manifest() in manifest.c has me puzzled. It adds
a line of junk to the end of a manifest to create a file that can't be
interpreted as a control artifact if checked into another repository.
This is used, iirc, to
9 matches
Mail list logo
