User Details
- User Since
- Dec 6 2017, 9:25 AM (232 w, 21 h)
Tue, May 17
I think there are two issues here. The format string in line 500 doesn't match 492 and the format string in 494 doesn't either.
Thu, Apr 21
This is a proof-of-concept still, not for actual merge.
Apr 6 2022
Mar 29 2022
default should be fine. There are a number of places that don't necessarily work correctly for miss-ordered parents, but that's been the default behavior for years too, so nothing new.
Mar 27 2022
Oh, sorry. I thought you returned the slice directly, which should avoid some extra memory allocations.
Well, for DOS-style line ending, the find will point to the \n and we should return everything before the \r. If we ignore line endings mixed with old Mac-style, just checking the character before is enough to cover both DOS and Unix convention.
Note that you should at least try to check if text[i-1] is \r, otherwise the result changes from before. I'm perfectly fine with not supporting the ancient Mac convention of using \r only, but we should work properly for DOS-style \r\n.
Mar 25 2022
I wonder if we shouldn't optimize for the common case of multiple lines by using find() instead. Searching for \n first and \r second (in the substring if the first got a hit) and only then slicing the result.
Mar 24 2022
Mar 22 2022
Why not pickable = sorted(heads)?
Mar 21 2022
Mar 2 2022
Please fix the comment to something like: Python 3 file objects set the initial position consistently for append mode and can be used directly or something like that. The current comment doesn't make sense without the context.
Feb 21 2022
Feb 7 2022
Why do we want this variant of a rank? E.g. an alternative definition of rank is the length of the longest path to root. That definition is much easier to compute incrementally and just as useful for most algorithmic uses.
Most of v1 and v2 is shared and duplicating all of that just adds complications for no gain.
This is reasonable, but I didn't double-check that all cases are identical.
I'm not a fan of this change, it seems a step in the wrong direction.
Jan 27 2022
"fast to general locally" in the description needs a fix. I wonder if we should introduce a new set for such features, I expect similar cases to occur in the future.
Jan 17 2022
Jan 8 2022
Jan 3 2022
Jan 2 2022
Dec 23 2021
Sep 18 2021
Sep 17 2021
From the VC call today: The use case can be addressed by marking parents as to-be-preserved, so that for merge commits rebase can decide on the parent link is should operate on. It covers a general DAG and is somewhat easier to use in terms of UX than the parentmap, but can provide the same functionality with a multi-step rebase.
Aug 4 2021
Jul 20 2021
I would have to reaudit the parents use, but it wasn't just new code that misbehaves on misordered parents. E.g. memctx.parents for a trivial example. So yes, just backing it out introduces regressions as well.
Jul 6 2021
Just the revert as is introduces other regressions. At the very least, we should preserve the sorting for changelog and keep the original order for filelog. The other part is that the filelog logic here is actively broken even before, so this doesn't fix the logic, just makes it less visibly broken.
Jun 21 2021
Can you comment on how many of them we keep open at a time?
May 27 2021
Consider it more a -0, not a very strong objection.
May 20 2021
Correct, this stack should have beeen superseded by those.
May 19 2021
May 18 2021
May 17 2021
May 16 2021
There are three stages for the revlog and I think we need to teach the transaction playback code at least a bit about this to handle it correctly:
This whole stack exposes a real problem and one quite a bit older, but it is not correct in a number of ways as is.
May 15 2021
May 14 2021
Silly Python, but this should be fine for all versions we care about. Ironically, it used to be defined the other way around as alias...
May 11 2021
May 4 2021
Adding more files to the revlog layer sounds like a move in the wrong direction and the motivation here seems quite weak too. Please discuss this with an actual plan on the mailing list.
I don't understand the motivation for this change.
I don't understand this change. We already support none as compression method.
May 3 2021
This adds a penalty for the non-inline case?
Apr 30 2021
I'm not sure that this is an improvement. We discussed whether we want to hard-wire the version even stricter ("exactly version 11"), especially because it is hard to predict when the output is going to change again.
Apr 29 2021
Already merged as d55b71393907
Apr 28 2021
Merged as 8d2b62d716b0
Merged as 77e73827a02d