centralized repo to store tasks and task stashes

alu avataralu created an issue

From a comment on my blog:

In a previous thread I read that Bill Barry has a centralized repository for his attic changes. Would it be
possible to have a  centralized repository for the tasks and task stashes? This would allow people to see
the current tasks I’m working on and provide me with a way to easily backup my tasks in the event that my
computer blows up or is stolen. If so, this would make for one heck of a workflow.

Comments (6)

  1. alu

    OK guys, please give me more input on what exactly is wanted here.

    I'm not sure I see an easy way to store tasks themselves remotely.

    I see from http://www.selenic.com/mercurial/wiki/index.cgi/AtticExtension that you can version the .hg/attic directory. This works well because each 'shelved work' is its own file, so there is no conflict and merging required unless you work on the same 'shelved work' - in which case you expect to have to merge. Tasks are stored in the same way as bookmarks in a single file (with an optional stash which in my mind was always meant to be local...)

    For sharing, I thought we would make .hg/tasks another hg repo and then I would piggyback normal "hg push" with a second "hg tpush" command which would then share the relevant tasks. Because tasks are just pointers to changesets already *in* your history, then you can't really use them in a throw-away fashion if you want to share them. Locally they are easy enough to throw away (hg strip taskname), but what can you do once it is pushed? You would have to synchronize your 'strip' command with whomever you share changesets with - hg doesn't facilitate anything like that unfortunately.

    Another issue is that tasks right now are not limited to branches, and you can have overlapping tasks (changesets belonging to more than one task.) I left this in deliberately, but I'm not sure how useful it is.

    Now what if tasks were smarter and knew if they were pushed or not. Let's imagine we start a task and commit some changesets to it. We don't mark it as complete, so it does not get pushed to our upstream repo. But we do want to share it, so imagine we do something like "hg tpush mytask". This would then convert all task changesets to a patch series which is then shared to the upstream "task repo". Anyone can tpull from the "task repo" and it will then recreate local changesets and task metadata (maybe using 'hg import --exact' ??, or maybe not..) How will conflicts be handled? not sure yet. Maybe last writer wins, maybe something smarter, not sure. Once a task (..all changesets belonging to a task) is pushed to the upstream repo then really there is no reason to share the task metadata any longer and it could them be cleaned from the "task repo".

    Right now attic offers a very easy way to collaborate on a features and you have the added benefit of versions patches so you can always go back. Tasks on the other hand just help you the creation of otherwise anonymous branches and suppress sharing changesets that are not ready to for the upstream.

    I really want to think of a way to share tasks and associated changesets but I need some input on how it should be done.

  2. bobpaul

    The official bookmarks extension now allows bookmarks to be pushed. Perhaps looking at what they're doing would allow tasks to be pushed easily.

    hg push --help
    ...
    -B --bookmark VALUE [+]  bookmark to export
    

    for task stashes, you'd probably need to do like attic does, but to be honest, I don't want to push task stashes. If I have something I want to share, I'm going to commit it and push that. If I don't want it to go upstream, I'll do a local hg serve and have my co-worker pull the commit. If no other option, hg diff > patchfile.patch and send the co-worker the patch for them to apply to whatever revision I was working on.

    IMHO, what we really want to do is add a way to convert tasks to bookmarks (and back?) and then a user can use the normal method to export the bookmark. I mean, are we re-inventing the wheel? Maybe tasks should just BE bookmarks (and require the bookmarks extension is active) with the extra task specific meta data kept separate.

  3. alu

    I agree stashes should not be pushed.

    I have not been following the bookmarks extension since I took my 'hiatus' - which was before they were pushable. I will try to familiarize myself with this extension again.

    Have you thought more of using bookmarks for tasks? This is not a bad idea. We can even hide the 'task' bookmarks from general bookmark usage - by filtering the list.

    Would love to hear more about your ideas on this.

  4. bobpaul

    I think it would simplify long term maintenance to a large degree, and since bookmarks is a bundled extension, it shouldn't be a big issue to require users also enable that extension. It would mean we'd have to track 2 APIs, the bookmarks extension and hg itself, but we'd benefit from most/all fixes in the upstream bookmarks extension.

    I guess my immediate thought was just to let them show as bookmarks, so that "hg bookmarks" would show all bookmarks and tasks and "hg tasks" would show only tasks. But hiding tasks from "hg bookmarks" and then extending bookmarks with a "--show-tasks" option or similar option does sound like the cleanest implementation.

  5. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.