7 ms·

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a

The problem with Darcs, which I've seen in use, is that the tooling around it is atrocious. Compared to something like Bitbucket or GHE, it's a huge pain for a bigger team, and requires a very oldschool workflow. There's a Jenkins plugin that barely works, you have to build your own new version because distro packages are old, etc. Not sure whether there's any actual advantage at all.

pmeunier 7y ago
Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh (https://cargo.io/crates/thrussh https://cargo.io/crates/thrussh), which aim at making the UX as smooth as possible.
- the_duke 7y ago
  Correct url: https://crates.io/crates/thrussh https://crates.io/crates/thrussh
- core-questions 7y ago
  Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement. Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix. I am interested in https://www.unisonweb.org/ https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.
  - pmeunier 7y ago
    > gotta assume the work to bring them to Pijul would be just as much work Not really. If they're not heavily relying on the "darcs replace" feature, it's just the same interface. The dependencies between patches are computed differently. Be careful though, Pijul is still 0.12, the patch format will change. > I'd love to see this go further and have a "no conflict" merge take place This seems possible in a future Pijul. Right now we're just starting to get text files right! Let's see in a few years.
vmchale 7y ago
> the tooling around it is atrocious. Compared to something like Bitbucket I've yet to find anything comparable for repository hosting. I use it for projects where some of github's features are frivolous, but it would be a bit goofy adopting it at a big company.
gnufx 7y ago
I'd hope my revision control didn't need a lot of tooling, personally. I have Emacs darcsum and vc-darcs, and Trac integration, with hooks to use on commits etc. I guess darcsden (hub.darcs.net) is similar to pijul nest. There doesn't seem to be any real problem integrating it with things (that don't insist on a CVS-ish model) if people want to do it, it's just that few do, unfortunately. I haven't had time to see how easy it would be to provide darcs support for sourcehut, which might be useful. I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects, especially fixing incidental bugs in things I use. Each to their own, after some decades' experience of effective distributed development.
- core-questions 7y ago
  > I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects GHE is Github Enterprise. Most software development teams use that or Bitbucket or Gitlab, because there's a ton of value in the visual interface, the approach to code reviews, approvals, etc. that is hard to recreate in any other form. You still push Git patches to it the same way as you would to any other Git repo.

pmeunier 7y ago

Well, we (the Pijul team) are trying to learn from Darcs and not disregard that aspect. Darcs maintainers have been super busy fixing the performance issues, but since Pijul doesn't have those, we can invest more time in the tooling. Look at nest.pijul.com for example, or the satellite projects such as Thrussh (https://cargo.io/crates/thrussh https://cargo.io/crates/thrussh), which aim at making the UX as smooth as possible.

the_duke 7y ago
Correct url: https://crates.io/crates/thrussh https://crates.io/crates/thrussh
core-questions 7y ago
Thanks, this is fascinating. I'd been hoping to move one of my teams away from Darcs to Git but they're very set in their ways; gotta assume the work to bring them to Pijul would be just as much work, but then the other teams that use Git would also need to move. Way too much CD tooling to re-implement. Would consider for a new project, somewhere else, though. I really miss my perfect understanding of SVN when I get lost in some Git madness - it's obviously way more powerful and faster but sometimes I get into merge scenarios where I have to go edit files just to restore whatever I just did on another branch or what-have-you. Editors papering over this with extensions to "resolve using theirs" etc. help but seem like an ugly fix. I am interested in https://www.unisonweb.org/ https://www.unisonweb.org/ which I saw here recently as storing its code in a fundamentally different way that helps make ugly merge conflicts a thing of the past by making the on-disk format (and therefore the revision control system) aware of some aspects of the AST. I'd love to see this go further and have a "no conflict" merge take place as long as two edits to a single file touched different functions and the merged version passes some tests or whatever.
- pmeunier 7y ago
  > gotta assume the work to bring them to Pijul would be just as much work Not really. If they're not heavily relying on the "darcs replace" feature, it's just the same interface. The dependencies between patches are computed differently. Be careful though, Pijul is still 0.12, the patch format will change. > I'd love to see this go further and have a "no conflict" merge take place This seems possible in a future Pijul. Right now we're just starting to get text files right! Let's see in a few years.

vmchale 7y ago

> the tooling around it is atrocious. Compared to something like Bitbucket I've yet to find anything comparable for repository hosting. I use it for projects where some of github's features are frivolous, but it would be a bit goofy adopting it at a big company.

gnufx 7y ago

I'd hope my revision control didn't need a lot of tooling, personally. I have Emacs darcsum and vc-darcs, and Trac integration, with hooks to use on commits etc. I guess darcsden (hub.darcs.net) is similar to pijul nest. There doesn't seem to be any real problem integrating it with things (that don't insist on a CVS-ish model) if people want to do it, it's just that few do, unfortunately. I haven't had time to see how easy it would be to provide darcs support for sourcehut, which might be useful. I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects, especially fixing incidental bugs in things I use. Each to their own, after some decades' experience of effective distributed development.

core-questions 7y ago
> I don't know what GHE is, but making me interact with github or bitbucket isn't a good way to encourage me to contribute to projects GHE is Github Enterprise. Most software development teams use that or Bitbucket or Gitlab, because there's a ton of value in the visual interface, the approach to code reviews, approvals, etc. that is hard to recreate in any other form. You still push Git patches to it the same way as you would to any other Git repo.