On 10/15/21 2:22 PM, Pierre-Yves David wrote:
On 10/13/21 10:57 AM, Simon Sapin wrote:
Please let us know of any question or comment!
I remember discussion about storing WC exec-bit and symlink status to
help system without support for thoses (Windows we are looking at
you). That is necessary to solve things like "issue5883".
Storage wise this should be fairly simpler, so we should be able to
reserve some useful value for that in the new format. Regarding the
implementation of a behavior fixing the associated issues, it seems
complicated to get something done as the freeze is a couple of days away.
I just remembered this and I am not actively working on it today so I
don't have a very concret idea about it yet. Matt Harbison might have
more concretes idea about this.
Okay, so the core of the issue is : "Windows" has no way of storing the
exec bits in the file-system and since we read it from the file system
at commit time, we have no way to set it (or unset it) in general, and
during merges in particular. The solution people have been leaning at
for years is "store the exec bits in the dirstate entry for the file and
has some API (+ UI) to set/unset it.
So it seems like we need to reserve at least 2 bits for this.
(WC_EXEC_BITS, WC_SYMLINK), then comes the question of how do we manage
these two bits:
1) We could enforce them all the time, requiring `hg status` runs to
synchronize the value between the fs and the dirstate when they differ,
as 1 mean set and 0 mean unset. That approach requires more work but
would allow repository to move to a different fs without loosing
information.
2) We could have a third bits to indicate if the feature is in use.
Repository on file system that needs it could start using the feature
conditionally. This as the advantage that we just needs to reserve the
flags, and can implement the feature later, the code behaving as it is
today if that third flag is unset. However this means that moving
repository between file system might loose information.
In this scenario we would still need code to at least preserve the
existing value in the code.
I guess I'll start poking a (2) and see how much work it actually save
use compared to (1)
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel