Possibility to do something like "svn up -rX", with X < HEAD, to return to a 
previous version without loosing the changes. Like reverse applying all newer 
patches. "rollback" doesn't do this reliably and is also a bit inconvenient (I 
need to delete the inverse patches later).

Hi,

> Possibility to do something like "svn up -rX", with X < HEAD, to return to a 
> previous version without loosing the changes. Like reverse applying all newer 
> patches. "rollback" doesn't do this reliably and is also a bit inconvenient (I 
> need to delete the inverse patches later).

We usually do this by using 'darcs get' to make a branch, and obliterate
to remove the relevant patches.  You can also pass a --to-patch flag to
eliminate the need to obliterate.  Would that work for you?

In any case, rollback is very likely not the command you want for this,
as you observed.  It generates another patch.

Thanks!

devurandom wrote:
> New submission from devurandom <devurandom@gna.org>:
> 
> Possibility to do something like "svn up -rX", with X < HEAD, to return to a 
> previous version without loosing the changes. Like reverse applying all newer 
> patches. "rollback" doesn't do this reliably and is also a bit inconvenient (I 
> need to delete the inverse patches later).

darcs obliterate?

http://www.darcs.net/manual/node7.html#SECTION00795000000000000000

I know the variant with 2 repositories and pull/unpull. But I don't think it is 
very convenient. Instead I would like to just reverse apply all patches up to X 
to my workingcopy. This is in my opinion much more convenient than having to 
copy around repositories.

btw: obliterate is an alias to unpull. Why is it needed? I think it just 
confuses to have too many commands (or aliases).

> I know the variant with 2 repositories and pull/unpull. But I don't think it is 
> very convenient. Instead I would like to just reverse apply all patches up to X 
> to my workingcopy. This is in my opinion much more convenient than having to 
> copy around repositories.

I understand.  Bzr has this feature, I think.  Personally, I'm not keen
on the idea, because it introduces new commands/flags into darcs. But I
can also see that it might be very useful.

If anybody wants to implement it, perhaps a good user interface for it
would be to have a hide and unhide command, which would accept the same
patch matching arguments as obliterate and pull respectively.
Alternatively, we could also have some flags for obliterate and pull.

> btw: obliterate is an alias to unpull. Why is it needed? I think it just 
> confuses to have too many commands (or aliases).

Obliterate is the preferred name, deliberately chosen to be 'scary'
because the user might lose information by using it recklessly.  For
what it's worth, the unpull command is now hidden in the current stable
branch so that it no longer shows up in the help, or in autocompletion.

Sidenote: I think I said that already somewhere, but eg. I had no idea what 
obliterate meant till I looked it up in the dictonary (and of course I didn't 
look it up when I scanned the commandlist). In fact the first page(s) of the 
google(.de) search are references to dictionaries, as if that word wasn't 
commonly used. Something like erase might have been a better choice...

> > I know the variant with 2 repositories and pull/unpull. But I don't think it is 
> > very convenient. Instead I would like to just reverse apply all patches up to X 
> > to my workingcopy. This is in my opinion much more convenient than having to 
> > copy around repositories.

Another idea is to use darcs send -O to create a bundle, and darcs obliterate

I recommend resolving this as "wont-fix". I believe "darcs get --to-patch" is a
fine solution to the stated problem, and is much like the SVN solution. SVN
solution  also uses two copies of the tree (one in the server and one in the
client.)

I'm reopening this because of the repeated clamoring for the feature (which is
not to say that we'll definitely do it)

I used git for a project recently (by requirement, not by choice) and although I
detested how much branching was required compared to darcs, I appreciated the
"in-repo" branch management.

My own primary darcs-managed project is big and active enough that I now need to
have a feature-branch regularly, and can't get by with just spontaneous branches. 

My first approach was to just "darcs get" into a new directory, but then I
realized I needed a whole new set of Apache & and project configuration details
to match the new directory name.

So my branch management in darcs now looks like this, to switch from my trunk to
a branch:

mv working trunk; mv branch working

Yes, I'm just swapping directories in and out to the same location. It works OK,
and at some level I like the simplicity of it. But from another angle, the git
approach of being aware of branches and managing them is also appealing. 

That said, at this point I don't have specific suggestions for how the darcs UI
might handle something like this, and I would want to consider that carefully
before deciding that we should really have this feature.

I'm noting a purely UI-level suggestion here (discussion on mailing list,
please, if wanted) for in-repo branches:

1. Darcs repositories can be stored _darcs/branches.  They can (be seen as)
regular repositories in every sense of the word.

2. Darcs commands accept a --branch flag.  For example, darcs push /foo/repo
--branch bar is exactly equivalent to darcs push /foo/repo/_darcs/branches/bar

3. We could supply some sort of "darcs switch" command that lets us hop from one
branch to the other.  On a high level, it could be seen as being some
combination of obliterate and pull.

This is near the top of my wish list for darcs as an experienced git user. I
have been researching darcs for quite a while now, and I can get by without most
of the other git-centric commands. However, I think cheap (and fast) local
branching would make converting git users to darcs much easier.

Just like what was said in msg7406, switching between branches within the same
directory has been very useful. The ability to have multiple topic (or local)
branches in the same repository allows you to keep only one working copy thus
saving a tremendous amount of disk space. For users hacking on projects which
take up a lot of disk space, this could be invaluable.

One excellent ability would be for us to query a list of local and/or remote
repository branches. And perhaps (like with git) the ability to save aliases of
known remote darcs repositories for ease of use. (For example, just like git
remote and git branch, a darcs remote and a darcs branch.) Just take a look at
the git documentation for git checkout, git branch, and git remote.

Anyway, even though I'm the git guru at my workplace, I'm switching to darcs!
Keep up the great work!

Max, would you mind making a note of your idea from
http://irclog.perlgeek.de/darcs/2009-07-12#i_1310471 ?

Thanks!

Eric Kow wrote:
> Eric Kow <kowey@darcs.net> added the comment:
> 
> Max, would you mind making a note of your idea from
> http://irclog.perlgeek.de/darcs/2009-07-12#i_1310471 ?

Certainly.

Here's a quick primer: Basically, darcs >= 2.0 uses a hashed pristine 
store that acts as a file object cache. An interesting artifact of the 
pristine.hashed store, which is being pushed into a useful third-party 
accessible library named hashed-storage, however, is that it does (for 
many reasons, most co-evolutionary) resemble the git object store. There 
are several differences, but one of the key differences that applies to 
the topic at hand is that darcs generally garbage collects 
pristine.hashed objects much faster than git.

Darcs is very quick to garbage collect old objects partly because many 
aren't all that useful, but mostly because the primary representation 
for a repository state is the patch store (and inventory), so there is 
only one root pointer in the pristine store. Petr, the author of the 
hashed-storage library, briefly discusses this in his most recent design 
post about the future of hashed-storage:

http://mornfall.net/blog/designing_storage_for_darcs.html

Here's where the primer meets the topic at hand: A darcs branch consists 
of three major components: an inventory store, a patch store, and a 
pristine store. To store multiple branches "in the same place" you need 
to take care of: 1) storing the alternate inventories, and 2) if you 
want it to be relatively fast, storing additional objects in the 
pristine store. (The patch store will already happily hold more patches 
than are referenced in the current inventory.) (1) is mostly a matter of 
naming alternate inventories and swapping between them. Thanks to the 
*ahem* git-like nature of pristine.hashed/hashed-storage: darcs could 
easily archive (many) more pristine objects, than it will during normal 
operation, in pristine.hashed and it may be as simple as storing 
additional, useful "root pointers" visible to hashed-storage so that it 
knows not to garbage collect the objects from other branches.

Here's where the fun happens: It seems to me that a branch switching 
tool, utilizing darcs' existing repository data stores, could be built 
almost "purely" on top of mostly just the hashed-storage library (which 
has been designed for reuse), as it exists today or hopefully with only 
minor tweaking, and with only minimal interaction with darcs itself. 
That is, in-repo branching could be provided entirely, today or soon, as 
a second/third-party tool to darcs. (!)

I think this is great from a darcs perspective: darcs itself remains 
conceptually simple (1 repository == 1 branch), which is something that 
I for one love about darcs, and doesn't need additional commands in 
darcs iteslf. But yet, power users (and git escapees) would have easy 
access to a ``darcs-branch`` tool that provides simple and powerful 
in-repo switching. Potentially, such a tool is also a great candidate to 
be an earlier adopter for the darcs library support and can help better 
define and enhance darcs' public API. (It's also interesting in that it 
mirrors that hg's support for branches is an addon, and that both hg and 
git have darcs-like patch queues as addons.)

I think this is even better from a hashed-storage perspective: 
``darcs-branch`` would be a strong (new) use case for hashed-storage as 
a public API. The tool would provide good incentive to keep 
hashed-storage's API clean, and better incentive (than darcs' normal 
operation) to keep hashed-storage's garbage collection and object 
compaction strong. (With the 'cheap' cost of in-repo branches primarily 
a consequence of how well hashed-storage stores the additional objects 
of multiple branches. As a bonus, normal darcs operations should benefit 
as well from the gc/compaction optimizations that darcs-branch 
operations may make more obvious.)

At a high-level, a ``darcs-branch`` tool would provide core commands to:

1) Store the current repository state as a new branch by copying the 
current inventory and inserting a new pristine root for the branch. 
(``darcs-branch new`` or ``darcs-branch freeze``, perhaps)

2) Switch to a previously stored branch, by making the branch's 
inventory the new current inventory and the branch's pristine root the 
new current pristine root; updating the working directory as necessary. 
(``darcs-branch switch``)

Additionally, there would be other useful management tools 
(``darcs-branch list``, ``darcs-branch remove`` (or unfreeze)). I think 
that these four commands could be done with no darcs interaction at all 
(unless the branch being switched to has an incomplete/lazy pristine).

Useful commands that would need darcs interaction for patch management 
would be things like ``darcs-branch push`` to push patches between named 
branches (equivalent at a high level to ``darcs send -o new.dpatch 
--context branchB.context; darcs-branch switch branchB; darcs apply 
new.dpatch``), and ``darcs-branch obtain`` to obtain new in-repo local 
branches from an existing context file, remote/external-local 
repository, tag, or other matcher (that is, darcs get from one in-repo 
branch to a new one).

I doubt that a ``darcs-branch get`` to download all of the branches 
other than "current" (or HEAD, if you prefer, or "main" as I prefer) of 
a remote repository would need any darcs interaction (downloading the 
inventories and then many/most/all of the pristine objects). We can bet 
that darcs' usual lazy patch-getting behavior should work out of the box 
even for multiple branches.

Well, that's the general idea, at least. I believe that a willing 
volunteer and a bit of help from Petr could build such a tool 
"relatively quickly" and hopefully might even possibly work with today's 
darcs as it is.

(The chat log then wanders off from this starting point to wondering if 
auto-named branches might be useful than tags in generating the usefully 
secure revision identifiers that are asked for...)

I'm just bookmarking Stephen's comment here because I keep looking for it:
> Darcs branches are also conceptually expensive because I
> have to decide where to put them, and I have to remember where they
> are when I want to refer to them.

http://lists.osuosl.org/pipermail/darcs-users/2008-November/016063.html

On Tue, 21 Jul 2009 21:09:45 +0000
Eric Kow <bugs@darcs.net> wrote:

> 
> Eric Kow <kowey@darcs.net> added the comment:
> 
> I'm just bookmarking Stephen's comment here because I keep looking for it:
> > Darcs branches are also conceptually expensive because I
> > have to decide where to put them, and I have to remember where they
> > are when I want to refer to them.

I agree.

My little time re-invented branch management with darcs, by having the
current working directory be a symbolic link to a physical branch.  It's
simple, fairly fast to use and works well enough, but I would like
darcs to be involve to enforce standardization here.

    Mark

like it. git branches are nice to work with, and they don't the
conceptual pain of "creating" an new repository.

Things that make them nice:

 * When switching branches, all your files magically update (if they
have not been modified).
 * Easy to maintain multiple branches, say "stable" and
"experimental". That helps me avoid getting clobbered by other's
changes to APIs I depend on.

Things that are a pain:

 * Comparing commits (patches) between branches. Its hard to tell
what is one and what is in another.
 * When you have modified files, git is super picky about switching branches.
 * Once a remote branch is pushed to a public repo, its scary to
remove it. You don't want to break somebody, but you don't want that
old junk hanging around either.

I don't mean to write about git, but if darcs was to have branches,
thats the kind of stuff I would love to see.

Responding to msg7987:

Well, I believe your woes with comparing commits between branches isn't too hard
to solve with git: "git log <from_ref>..<to_ref>". That command finds patches in
tree to_ref which are not contained in tree from_ref. 

However, the interface just isn't very intuitive. Most people don't read the
manual pages, which can get annoying, but let's be honest--they're not very
human friendly. I would guess only a small minority of git users actually
understand what the .. and ... mean in the git log command.

I agree with your comment about the pains with switching branches. It should
ideally let you pass an option which "git stash"es your changes for you leave a
branch and automatically reapplies them when you come back to that same branch.

Hopefully Darcs devels will grace us with something smarter :)

There isn't yet very much consensus about what is the right way to do this.  In
the meantime, I'd like us to defer this until we've resolved some potential
pre-requisites:

issue431: --no-working-tree
issue1505: hashed context files
issue1504: plugin mechanism

None of this commits us to Max's plan, but if we did have these pieces in place,
we may have a clearer idea about how to go forward.

Attached is a very rough prototype of a "darcs-branch" command.  It works 
by copying hashed_inventory files around and using revert to switch 
between branches.

See mailing list for discussion: http://lists.osuosl.org/pipermail/darcs-
users/2012-March/026435.html

Attachments

• darcs-branch

Apart from switching between branches (hiding and unhiding changes), 
branches in Git are important for me to inspect the history of the 
project and the available variants in form of a graph (almost a "tree" -
- if there were no merges).

If branches are external to darcs (which is not necessarily bad: it's 
nice not have additional things if they can be done elsewhere, i.e., in 
the filesystem in the case of branches), then I'd like it if there was 
an aggregator tool for all known "branches" (darcs repos) that would 
display their states as a tree. (darcs doesn't store the tree, but a 
tree view could be contstructed.)

I see the aggregated tree view for all/selected known darcs repos as a 
part of the wish to have something like branches.

On 06/16/2013 08:37 PM, Ivan Zakharyaschev wrote:
> 
> Ivan Zakharyaschev <imz@altlinux.org> added the comment:
> 
> Apart from switching between branches (hiding and unhiding changes), 
> branches in Git are important for me to inspect the history of the 
> project and the available variants in form of a graph (almost a "tree" -
> - if there were no merges).

I agree. I love the "Network view" on Github. Darcs has some awareness
of related branches through this command:

   darcs optimize --sibling=URL

It's used to link "sibling" repos together to save space. However, its
likely an inadequate or inappropriate foundation for the complete branch
awareness you are asking for.

   Mark

Technically, the branches could see as "color tags" of files. We just 
simply add a tag to one or several files. For example:


~ darcs add foofile tobranch foobranch
~ darcs list foobranch
  foofile

By default darcs create-branch could initialize an empty branch (no 
files) or a copy of a current branch.

With this, we can join branches easyly because we should join only a 
"color marked" files. And it's cheap, because we should just to make a 
ln to versioned file to corresponding branch.