Pijul

Preparing pijul-0.11.0


#1

As I mentioned here and there (including on IRC), I am in favor of monthly release of pijul, until we hit pijul-1.0, with regular release candidates (ideally one per week) and call to test the angry bird.

Also, I am committed to write better ChangeLog. So, here is the pending ChangeLog for pijul-0.11.0.


pijul-0.11.0 (unreleased)

Enhancement

  • Mimic the behaviour of darcs show dependencies by splitting the patch name
    into several names and by using a left-to-right layout with dot (was
    top-to-bottom before) (rc1, @lthms).
  • Give to pijul rollback a proper CLI, very similar to what pijul record and
    pijul tag already allow (rc1, @lthms).
  • There is now an help notice for patches selection, using ? (rc1,
    @FlorentBecker, @lthms)
  • Improve the patch summary presentation (rc1, @lthms)
  • You can now override the global pijul configuration directory, which is
    ~/.pijulconfig by default (rc1, @yory)
  • pijul status prints the current branch in addition to pending changes and
    conflicts (rc1, @laumann)
  • pijul fork gets a new option --tag to create a new branch with the minimal set
    of dependencies for a given tag (rc2, @lthms)
  • <C-k> when writing a patch name will now erase what is after the cursor
    (rc2, @pmeunier)
  • It is now possible to jump from one word to another with <C-←> and <C-→>
    (rc2, @pmeunier)
  • pijul dist removes the archive in case of failure (rc2, @lthms)
  • pijul dist now offers a new --stdout option to print the resulting archive
    to the standard output (rc2, @lthms)
  • Pijul now supports partial clones, meaning you can select a path within your
    repository, and only the patches required to output the content of this path
    will be pulled (rc2, @pmeunier)

Bugfixes

  • pijul was using a pager, even if the NOPAGER environment variable was set
    (rc1, @lthms)
  • pijul was not using a pager for the log command (rc1, @lthms)
  • While selecting changes to record, the d option (done, that is skipping the
    remaining changes) was behaved incorrectly with -n option (rc2, @pmeunier)
  • pijul checkout could fail sometimes because of Sanakirja specificity (rc2,
    @lthms)
  • pijul pull and push were failing when used to target another branch than
    the current one, both locally and remotely (rc2, @lthms)

Dependencies

  • ignore: 0.3 → 0.4 (rc1, @lthms)
  • bincode: 0.8 → 1.0 (rc1, @lthms)
  • regex: 0.2 → 1.0 (rc2, @yory)

Known Issues

  • pijul record may fail when used with the --branch option (see #271)

#2

that’s great, I’ll gladly help with testing.


#3

Okay, so I have tagged a 0.11-rc1 version which won’t be published to crates.io due to a bug in cargo. I have created a new branch called testing, so you can just use it since forking from a patch is not yet completely ready.

This means there is now three branches in pijul upstream:

  • master, which contains the accepted changes
  • latest which reflects the latest published version on crates.io
  • testing which will be updated once a week with a release candidate version to test.

Beware that, it is not because a patch finds its way to master that it will be added to testing at the end of the week. The main idea is that latest and testing should not have too big issues, whereas master may be broken from time to time (but of course, we want to avoid that also).

Happy testing, and thanks by advance for your time and reports (if any). Released notes have been updated accordingly :).


#4

I gave it a test, seems all good, just a small issue: when using ? in the record dialog, it repeats the commit message. I think there’s no need for that, actually it’s kinda confusing.

added file new_file.txt

Shall I record this change? (1/6) [ynkadi?] ?

added file new_file.txt

Available options:

Also: there’s a typo in d: skip all rema I ning changes.

And a bug: say that I add 3 files. When recording, on the first file I type d. I expect it to stop. Instead it continues with the other files, as if I typed n.


#5

Thanks a lot for your feedback, @yory

Also, for the sake of exposure, I repost here a comment I made on one discussion of the Nest:


I had to merge my changes with your partial checkout patch. I have pushed everything to the branch master, so don’t forget to pull them before pushing again, in order to prevent conflicts on pijul upstream.

I think I will tag pijul-0.11-rc2 with “forking from a patch” this week-end, then a pijul-0.11-rc3 with “partial checkout” the week after (or whenever it’s ready, really).

After this third RC, and once stabilized, I think we will have everything we need to release pijul-0.11.0!


#6

Hi all :).

I have updated the first post with a preview of what pijul-0.11-rc2 will probably be. I plan to tag it and push it to testing as soon as line-0.1.5 is officially released on crates.io.


#7

What is this?

Also, what’s your plan for partial clones?


#8

You can have a look at the patch here, and for the motivation in the first message of this discussion.

See, in this very discussion:


#9

Ok, thanks for the clarifications. I have ideas to fix the space problem in Sanakirja, by allocating the file in chunks. The default size of a chunk is non-trivial to set.

The main blocker now is, I don’t know how OSX and Windows behave when mmap’ing a larger size than the file.


#10

Thanks for the heads-up!

Could you just tell us here what is the current status of partial clones? What is done, what remains to do/fix/etc.?

I’ve tried to clone https://nest.pijul.com/pijul_org/pijul with --path, without any success whatsoever, so I assumed it is still a work in progress.


#11

They work fine between repositories that support them, which is not the case of the Nest. The repository format changed a little bit, but just opening a mutable transaction is enough to convert old repositories to the new format.


#12

I cannot make it works locally, with a pijul freshly built with your patches.

mkdir test
cd test
pijul init
mkdir a b
echo test > a/test
echo foo > b/foo
pijul record -n -a -m "patch"
cd ..
pijul clone test test-partial --path a/
ls test-partial

Output is a b rather than test, which I was expected.


#13

The expected here is just a: a partial clone will have the same hierarchy, but it will neither:

  • apply the patches that relate exclusively to other parts of the repository.
  • nor output these other parts (if they are created from a patch that touches both a and other parts).

There is a test case in the repository, called partial.bats, which passed last time I checked. Could you try to create a new test from that one, and modify it to make it fail?


#14

I will. If I understand correctly what I read, the test is aboul partial pull, rather than partial clone.

I am not convinced by this behaviour, to be honest. I’d prefer how svn works. Is it a planned feature?


#15

Clone is actually implemented as “init” followed by “pull”.


#16

Done!


#17

Done!


#18

Sometimes, the smaller patches have the biggest impacts :D.

Edit: I have been able to make it works! But I need to clone the project once first, then reclone the new project with --path.

Congrats! This is an awesome new features! I wish we will be able to have a word about partial clones in practice, now that the theory is correctly implemented.


#19

I will tag a rc2 today, with the complete changes inside master, for folks to test.

There is one known bug to be fixed before the release, plus something related to Windows and OpenSSH I haven’t had the time to dive into. That is without counting on all the bugs testers will found :D.

Will update the ChangeLog notes of this post, too.

Edit: Done! The testing branch has been updated.


#20

Ok, latest stable pijul, from fresh clone of master:

~/.cargo/bin/pijul pull https://nest.pijul.com/pijul_org/pijul --from-branch testing --to-branch=testing
Pulling patches: 100% (111/111), done.
Hash: 9tNKV1UL5cYbw3gpDScSfoZSRthQ3a6KHHKMQTjA1CyCumqrVcXey6t37qJMHURpZQwZt1UsKoj3bhNPfevwdhTK
Authors: ["Pierre-Étienne Meunier <pe@pijul.org>"]
Timestamp: 2018-02-27 14:44:24.130178136 UTC

    Init

Shall I pull this patch? [ynkad] a
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.25.0-src/src/liballoc/vec.rs:1551:10
note: Run with `RUST_BACKTRACE=1` for a backtrace.
export RUST_BACKTRACE=1 && ~/.cargo/bin/pijul pull https://nest.pijul.com/pijul_org/pijul --from-branch testing --to-branch=testing
Pulling patches: 100% (111/111), done.
Hash: 9tNKV1UL5cYbw3gpDScSfoZSRthQ3a6KHHKMQTjA1CyCumqrVcXey6t37qJMHURpZQwZt1UsKoj3bhNPfevwdhTK
Authors: ["Pierre-Étienne Meunier <pe@pijul.org>"]
Timestamp: 2018-02-27 14:44:24.130178136 UTC

    Init

Shall I pull this patch? [ynkad] a
thread 'main' panicked at 'index out of bounds: the len is 0 but the index is 0', /build/rust/src/rustc-1.25.0-src/src/liballoc/vec.rs:1551:10
stack backtrace:
   0: std::sys::unix::backtrace::tracing::imp::unwind_backtrace
   1: std::sys_common::backtrace::_print
   2: std::panicking::default_hook::{{closure}}
   3: std::panicking::default_hook
   4: std::panicking::rust_panic_with_hook
   5: std::panicking::begin_panic
   6: std::panicking::begin_panic_fmt
   7: rust_begin_unwind
   8: core::panicking::panic_fmt
   9: core::panicking::panic_bounds_check
  10: libpijul::optimal_diff::add::<impl libpijul::backend::GenericTxn<A, R>>::add_lines
  11: libpijul::optimal_diff::<impl libpijul::backend::GenericTxn<A, R>>::diff
  12: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::diff_with_binary
  13: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_inode
  14: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, R>>::record_children
  15: libpijul::record::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::record
  16: libpijul::apply::<impl libpijul::backend::GenericTxn<sanakirja::transaction::MutTxn<'env, ()>, T>>::apply_patches
  17: libpijul::apply_resize
  18: pijul::commands::remote::Session::pull
  19: pijul::commands::pull::run
  20: pijul::main
  21: std::rt::lang_start::{{closure}}
  22: std::panicking::try::do_call
  23: __rust_maybe_catch_panic
  24: std::rt::lang_start_internal
  25: main
  26: __libc_start_main
  27: _start