On 09/30/2016 08:56 AM, Ivan Shapovalov wrote:
On 2016-09-28 at 12:17 +0200, Edward Shishkin wrote:
On 09/27/2016 11:51 PM, Ivan Shapovalov wrote:
On 2016-09-27 at 23:47 +0200, Edward Shishkin wrote:
On 09/27/2016 08:36 PM, Ivan Shapovalov wrote:
On 2016-09-27 at 16:13 +0200, Edward Shishkin wrote:
On 09/27/2016 04:43 AM, Ivan Shapovalov wrote:
On 2016-09-27 at 00:37 +0200, Edward Shishkin wrote:
On 09/27/2016 12:05 AM, Ivan Shapovalov wrote:
On 2016-09-24 at 22:16 +0200, Edward Shishkin wrote:
Hello everyone,
I have set up the updated Namesys repositories at my
Github
page.
Those repositories are supposed to contain the latest
updates
in
the (stable) master branch and in other
(experimental)
branches
that
I'll announce.
1) https://github.com/edward6/reiser4
This is a "standalone" reiser4 tree, which doesn't
include
specific
changes of Linux kernel needed for reiser4 port. Such
changes
can
be
found at the project's page on Sourceforge:
https://sourceforge.net/projects/reiser4/
An example of work with the standalone reiser4 tree:
. Patch the respective kernel with the latest
available
stuff
from
Sourceforge;
. cd to the "fs" directory;
. delete the directory reiser4;
. instead of the deleted stuff clone the standalone
reiser4
repository from Github;
. build and install as usual.
2) Libaal and Reiser4progs:
https://github.com/edward6/libaal
https://github.com/edward6/reiser4progs
Before building Libaal and Reiser4progs execute the
./prepare
script,
which will create files needed for build process.
Thanks,
Edward.
Wow, finally.
Maybe we could avoid that "all changes for 10 years"
commit?
Hi Ivan,
Sorry, don't have a time to granulate it.
I tried to keep track of all patches since 3.2...
There will be "all changes for 6 years" commit.
Is it much better?
So well, I finished splitting off all known diffs from that
big
commit.
Tt was 12k(+)/8k(-), now it is 7k(+)/7k(-).
The updated branch is here: https://github.com/intelfx/reis
er4
(unfortunately, not fast-forward).
Moreover, my tree has accumulated quite a few differences
from
your
one. I've dropped trivial discrepancies (comments,
formatting
etc.)
and put the larger ones in separate branches:
1. https://github.com/intelfx/reiser4/tree/differences/enot
ty
(unsupported ioctls return -ENOTTY, not -ENOSYS)
2. https://github.com/intelfx/reiser4/tree/differences/migr
atep
age
(the ->migratepage() implementation, which I still do
not
completely
understand, but it works)
3. https://github.com/intelfx/reiser4/tree/differences/rena
meat
2
(renameat2(RENAME_NOREPLACE) implementation, which
you
haven't
merged somewhy)
4. https://github.com/intelfx/reiser4/tree/differences/adju
st-t
o-3.
15
(part of porting to 3.15 which, again, you haven't
merged
somewhy)
These branches are on top of that granular "master".
Anyway, please take a look.
It was definitely useful work,
I'll look at those differences..
Maybe you could also consider rebasing things on top of that
extracted
granular history?
Interesting idea, but I am not able to estimate
complexity of such rebasing for now.
While we do not have any forks and can afford non-fast-forward
updates
of master, the complexity is almost nil.
To rebase your format41 branch, one can do this:
git rebase --preserve-merges --onto
3c7b3c5802e20381496f641fe64b6c1573228c6e
8a896fd48ed35c7dfa0188f9b7f4cbdfd469cacb format41
where 8a896fd is merge-base of format41 and master (that big
commit),
and 3c7b3c5 is the corresponding commit of the synthesized history.
Both commits have identical file content (`git diff 8a896fd
3c7b3c5`
yields empty output).
OK, everything went smoothly,
Thanks for scrupulously archiving things!
Edward.
In meantime, I have also generated a history of the kernel side changes
(again, starting with 3.2). They are pretty small.
Do I understand correctly that the kernel folks are reluctant to merge
these ~150 lines?
They are reluctant to merge stuff, which is not used by any subsystem
of upstream kernel.
Edward.
--
To unsubscribe from this list: send the line "unsubscribe reiserfs-devel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
