[darcs-users] Accessing old versions
droundy at abridgegame.org
Sat Mar 13 23:25:04 UTC 2004
On Sat, Mar 13, 2004 at 10:22:28AM -0800, Kevin Smith wrote:
> David Roundy wrote:
> >On Thu, Mar 11, 2004 at 12:08:12AM -0800, Matt Ettus wrote:
> >>I can't seem to find a darcs command to move my working copy to an older
> >>revision or tag. Something like "cvs update -r OLD_TAGNAME" Am I totally
> >>blind? dumb?
> >I'm not entirely certain what you want to do here. Do you want to go from
> >an older version to a less old version, or to go from a new version to an
> >old version? The former can be accomplished with "darcs pull --tag-name
> I interpreted the question as "Given a repo, how can I get a working
> directory that represents an older version (tag) from that repo."
> The way I would do that is to leave the existing repo alone, and create
> a new copy of it using "get" with --tag-name.
> [cut nice explanation of mental shift coming from CVS to darcs]
I just noticed that Matt replied just to me, clarifying that this is what
he wanted, and I replied to him (intending to redirect it back to the list,
but forgetting) with almost precisely what you said below. :) That is, I
gave the the same solution, but without a somewhat different explanation,
because Matt clarified his example case a bit more. I include below my
email (and part of his) in case anyone else finds it helpful.
On Thu, Mar 11, 2004 at 09:59:46AM -0800, Matt Ettus wrote:
> Quoting David Roundy <droundy at abridgegame.org>:
> > I want to go from a new version to an old one.
> Let's say I'm working on a project, and put out a stable release, and tag
> it as REL1. Then I go and make a number of big changes, and check in
> many times. My latest code is unstable, so all my users are on REL1 and
> I have to maintain it. Somebody sends me a bug report on REL1. I want
> to make a patch to REL1 and cut a new release, 1.1, without using all of
> the other new changes I have made since REL1. This is pretty easy to do
> in CVS.
I use "darcs get --tag-name" for this. This gets a clean copy of the repo.
Assuming you run the get from a local directory, this uses hard links for
the patches, so the disk space cost is just two copies of your project
contents, and it's reasonably fast. After you make your changes to REL1,
you can then record them, tag the new version (REL1.1) and pull everything
into your latest release (hoping for no conflicts), so you'll have one repo
which has the fixes, and knows that version REL1.1 is. Or if you wanted,
you could not pull the changes (perhaps they are ugly changes you don't
want or need in REL2), and leave the REL1.1 version as a separate branch,
which would mean keeping the REL1.1 repo around in case you need to make a
More information about the darcs-users