Ketil Malde | 1 Jun 08:35 2005
Picon
Picon

Re: Feature requests

Remko Troncon <remko <at> psi-im.org> writes:

> 1. A command to list the patches depending on a certain patch. Currently,
>    i have to pull the patch in a working copy, and see which patches it
>    pulls with it.

Me too!

> 2. A way to merge different patches into 1 patch. Currently, i unrecord
>    patches one by one, and then do a big record afterwards.
>    I realize this will give nasty effects when patches leave the repository,
>    but i still would have massive use of this.

Would a tag help you?  I.e. create a tag that depends on (just) all
the wanted patches and their dependencies.  I'm not sure how general
the tag mechanism is, but it would perhaps be nice if it was possible
to specify an exact set of patches (i.e. a subset of all patches in
the repo) to constitute a tag.  

Currently, I think you need to init a new repo, pull the desired
patches, tag, and push back the tag.

> 3. A way to generate a unified diff of changes between 2 branches. I can
>    get a ChangeLog between 2 branches by doing 'push --dry-run', but i would
>    like to get a unified diff as well.

Sounds reasonable.

-kzm
--

-- 
(Continue reading)

Thomas Zander | 1 Jun 10:04 2005
Picon

Re: Feature requests

On Tuesday 31 May 2005 20:47, Remko Troncon wrote:
> Hi,
>
> I've been using Darcs for a couple of weeks now, and i fell in love with
> it from the start.
>
> There are a couple of features i would really like to have in Darcs to
> make life easier for me:
> 1. A command to list the patches depending on a certain patch. Currently,
>    i have to pull the patch in a working copy, and see which patches it
>    pulls with it.

You currently can get that info from darcs, but its nowhere near readable.  
What I think we need in this case is a little front-end to present this 
stuff in a nice way.  I'm inclined to say some innovative GUI work is 
needed to do this in a user friendly manner.

> 2. A way to merge different patches into 1 patch. Currently, i unrecord
>    patches one by one, and then do a big record afterwards.
>    I realize this will give nasty effects when patches leave the
> repository, but i still would have massive use of this.

Same here;  I noted this feature earlier as a grouping of existing patches. 
Meaning a set of patches are grouped, but the individual patches still 
exist separately on disk sidestepping the problem you saw already.
Anyway; this is a good feature request;  could you check if its marked on 
the bugtracker as such? (follow darcs.net for the bugtracker)

> 3. A way to generate a unified diff of changes between 2 branches. I can
>    get a ChangeLog between 2 branches by doing 'push --dry-run', but i
(Continue reading)

Albert Reiner | 1 Jun 15:30 2005
Picon

Enforce, or propose, prefix etc. for patch name?

Hi,

it seems that patch naming conventions are quite important in darcs
(which is again something I like).  But this comes with some problem,
viz., the danger of accidentally violating that naming convention.
The fact that patch names are part of the identity of the patch (which
precludes re-naming) doesn't make things easier.  E.g., in one repo I
have marked some patches with [lik] and some with [likning] even
though all of them refer to the same (nasty) entity.

So I am looking for a way to compensate for my lack of discipline.
What I would like is some way to make sure that, e.g., patches
recorded from a particular repo always have those markers, or, better
still, to be asked about which markers I want to have.

One way to achieve this that I would find convenient is an optional
file under prefs (with the option of putting it, too, under version
control): if it is there, every non-blank line in it should be
considered as a format string to be applied to the patch name typed by
the user; and after entering the patch name a menu should come up
listing the available format strings and asking which one to apply, or
to use the patch name as entered.  If there are no format strings (or
the file is missing), that question should be skipped.

I have not seen anything like this in the 1.0.2 docs, but I may well
be missing something.

Regards,

Albert.
(Continue reading)

zooko | 1 Jun 15:38 2005

Re: Enforce, or propose, prefix etc. for patch name?


You could add this feature by having the EDITOR environment variable point to a
script that prompts for the tag, as you described, and then inserts it into the
logfile before invoking the actual editor.

I'm not sure where your script could find that logfile.

Long Live the Unix philosophy of loosely-coupled tools!

Regards,

Zooko
John Goerzen | 1 Jun 15:59 2005

Where Arch is going

Seen on debian-devel...

I wonder if it will ever be possible to achieve a greater unity between
Arch and darcs?  Perhaps an Arch backend for darcs is possible?

Incidentally, if they solve this, and also the UI issues, this could be
a better-darcs-than-darcs since it wouldn't have all the annoying
conflict issues.

But that may be a big If.

----- Forwarded message from Robert Collins <robertc <at> robertcollins.net> -----

From: Robert Collins <robertc <at> robertcollins.net>
Date: Wed, 01 Jun 2005 17:13:49 +1000
To: John Goerzen <jgoerzen <at> complete.org>
Cc: debian-devel <at> lists.debian.org
Subject: Re: Is Ubuntu a debian derivative or is it a fork?

On Wed, 2005-06-01 at 00:06 -0500, John Goerzen wrote:

> BTW, the baz folks could get some very neat ideas from darcs.  The
> "offline mode comes free" way of working is very nice, and the
> branching being easier than Arch is nice, too.

We have .. we're about 3 releases (~3 months) away from a full
pull-style checkout that will bring all the history and be branchable
via a simple cp.

This is part of our convergence with the bzr design, as bzr proves each
(Continue reading)

John Goerzen | 1 Jun 16:22 2005

Re: Where Arch is going

On 2005-06-01, John Goerzen <jgoerzen <at> complete.org> wrote:
> I wonder if it will ever be possible to achieve a greater unity between
> Arch and darcs?  Perhaps an Arch backend for darcs is possible?

Incidentally, this bazaar-ng tutorial seems strikingly similar to darcs
in some areas, right down to bzr send...

http://www.bazaar-ng.org/tutorial.html
Remko Troncon | 1 Jun 17:15 2005

Re: Feature requests

> You currently can get that info from darcs, but its nowhere near readable.  
> What I think we need in this case is a little front-end to present this 
> stuff in a nice way.  I'm inclined to say some innovative GUI work is 
> needed to do this in a user friendly manner.

Would you need a GUI for that ?
	bash$ darcs --deps -p "Name of a patch"
		Sat May 14 15:23:29 CEST 2005 bla <at> bla.com
			* Bla
		Sat May 14 15:23:29 CEST 2005 blo <at> blo.com
			* Blo
Of course, the -p can be ambiguous, so maybe it could even be done
interactively, where you select a set of patches, and return the series
of patches which are needed. Actually, this would just be a pull --dry-run
from a clean repository, only without needing to create a clean repository
first.
		
> Same here;  I noted this feature earlier as a grouping of existing patches. 
> Meaning a set of patches are grouped, but the individual patches still 
> exist separately on disk sidestepping the problem you saw already.
> Anyway; this is a good feature request;  could you check if its marked on 
> the bugtracker as such? (follow darcs.net for the bugtracker)

So, you would only have 1 changes entry for the series of patches, right ?
That sounds very good to me.  I'll check the bugtracker.

> You will then have loads of problems with file renames and moves being shown 
> as way too much text, though.

Well, you can't expect more from a unified diff, so i can live with that.
(Continue reading)

Albert Reiner | 1 Jun 18:08 2005
Picon

Re: Enforce, or propose, prefix etc. for patch name?

Thanks for your suggestion:

[zooko <at> zooko.com, Wed, 01 Jun 2005 10:38:30 -0300]:
> You could add this feature by having the EDITOR environment variable
> point to a script that prompts for the tag, as you described, and
> then inserts it into the logfile before invoking the actual editor.

That would not work (for me, at least), as EDITOR is only called for
the "long comment", which I use rarely.  Virtually all of my patches
just have a single line description.  The main reason why I have not
set --skip-long-comment by default is the not-too-rare case of
forgetting about the lack of readline support and messing up that
string with some attempted movement commands.

> I'm not sure where your script could find that logfile.

There is a --log-file option to `darcs record`.

> Long Live the Unix philosophy of loosely-coupled tools!

I'm not sure - personally I _like_ darcs.  Even though its interactive
nature defies the easy scriptability that lies at the heart of this
Unix "philosophy".

Thanks again,

Albert.
Erik Bågfors | 1 Jun 19:23 2005
Picon

Re: Re: Where Arch is going

On 6/1/05, John Goerzen <jgoerzen <at> complete.org> wrote:
> On 2005-06-01, John Goerzen <jgoerzen <at> complete.org> wrote:
> > I wonder if it will ever be possible to achieve a greater unity between
> > Arch and darcs?  Perhaps an Arch backend for darcs is possible?
> 
> Incidentally, this bazaar-ng tutorial seems strikingly similar to darcs
> in some areas, right down to bzr send...
> 
> http://www.bazaar-ng.org/tutorial.html
> 

Of course, the whole idea of bazaar-ng is to take the best features
from darcs, arch, svn, etc and make something even better.  Darcs has
some really great things when it comes to easy to use and
collaboration over emails etc. Stupid not to use those ideas.

/Erik
Tuomo Valkonen | 1 Jun 19:27 2005
Picon
Picon

Escaped characters

As of 1.0.3rc2 darcs seems to escape all non-ASCII in output, including XML
changes with colours and everything. This sucks. I have UTF-8 in author
names in my repositories, and I have told them to use it UTF-8 or stick to
ASCII, but now that UTF-8 is also is garbled and my HTML and RSS changelog
scripts are broken again. Is this supposed to be a rude "fix" to the
encoding wishlist item (http://bugs.darcs.net//Ticket/Display.html?id=352)
or what?

--

-- 
Tuomo

Gmane