That clarifies it, thank you. My only remaining comment is that I find
these commands clearly defined and consistent with the rest of the
darcs UI, but at the same time I consider them to have a niche
usefulness. I do not find a use for them in my workflows, but I'm sure
other people will. Now regarding if there is a better alternative to
them, I do not know. Since I do not see a use for them myself, I
cannot imagine a better way of doing something I do not do ;). This
proposal seems reasonable to me.
On 24 Nov 2009, at 17:33, Florent Becker wrote:
--nextPart1323724.XxME5LlBlx
Content-Type: Text/Plain;
charset="iso-8859-15"
Content-Transfer-Encoding: quoted-printable
Hi list, hi Dan,
and thanks for the review. Here come my answers.
The executive version is: fetch is for retrieving and *naming* a set
of patches into a file without applying them. You can then inspect
them in =
a=20
text editor, as you would with a sent bundle, and apply them, not
necessari=
ly=20
all at once.
If you're interested, I'll start be requesting on list that you
serve
as Grumpy Old Man for Florent's recent patch39.
Since you asked, I will not leave you empty handed, so I will give
my =20
input on patch39. Again I cannot read haskell code, so what I say
is =20
entirely based on the comments that accompanied the code.
Ok
I agree with Florent that fetch and unapply are 2 commands that are
=20
easily learnt and with clear semantics. From this point of view I
see =20
no reason against them.=20
Good
But from the user perspective, while Florent =20
calls them "very useful", I could not imagine a single use case for
=20
them. Maybe if I'm told one, I will have an a-ha moment and see the
=20
light. But right now I do not really understand how fetch can be =20
useful. There is no description how one can inspect a patch that
was =20
fetched to _darcs/pacthes but it was not applied. Even right now I
=20
still have patches that are in _darcs/patches but I cannot access =20
(patches I unrecorded/obliterated/amend-recorded). Or maybe he
plans =20
to store them in a different place.=20
Yes, that is the point, which i'm sorry if I did not make clear
enough, the=
y=20
are stored in a bundle file, not in _darcs/patches.
Contrarily to hg's and git's(?) fetch, darcs fetch gives you the
patches in=
a=20
simple bundle in the current directory (as does send -o),
*not in _darcs/patches*. This means that it does not modify the state
of the local repository. It offers you the patches for inspection by
puttin=
g=20
them into a file with the name of your liking.
You can then inspect that bundle using a text editor or whatever tool
you want. You can also keep it for later application, maybe in some
other=20
related repository, maybe not applying the patches all at once.
But then how is this different =20
than having a patch cache. Right now I can pull a patch, then
inspect =20
it with darcs diff or darcs changes, then obliterate it. Next time
I =20
pull it it will take it from the cache so no extra download will be
=20
necessary. How does darcs fetch improve on this?
It does not improve download performance at all! (Even if doing a
darcs fet=
ch=20
has the desirable side-effect of putting the patches in cache,
that's not t=
he=20
point of the command). However, you can fetch
several patches at once, and give a name to that set of patches.
Suppose fo=
r=20
instance that you want to port a feature from David's darcs to your
own dar=
cs=20
repository. The two repositories may have diverged, so the merge is
going t=
o=20
be a bit complicated. Currently, you have three solutions: either
you do a=
=20
pull, select all the relevant patches and then you have to solve all
the me=
rge=20
problems at once. Or you pull the patches one by one, but you need
to have=
=20
network connectivity for each patch, so you can't do that on a
train, and y=
ou=20
have to redo the work of sorting the remote patches every time.
Finally, yo=
u=20
can get your own repository into a new copy, pull all the remote
patches in=
to=20
that copy, then pull from the copy to your work repo. Then you have
to use=
=20
darcs changes to review the patches, and you have one more
repository. If t=
he=20
patches are small with respect to the size of the project, you use
more dis=
k-
space than you really should. With fetch, you just fetch, select the
patche=
s=20
you want, then use darcs apply -i fetched-patches.dpatch at your
leisure. I=
t's=20
like the last use case, except that it's more lightweight.=20
It scales better (at least for me) to have throwaway bundles for
sets of=20
patches which I may or may not want to apply than to have throwaway
repos f=
or=20
each such set of changes. Our workflow where we review sent bundles
is doab=
le=20
because we have send, and with fetch, we can extend it to pull-
requests: if=
I=20
want to examine a set of patches from someone's repo, i'd much
rather have =
a=20
bundle representing exactly the patches i want to pull than either
have to =
do=20
remote invocations of darcs changes before i pull or having to
create a ful=
l=20
repo every time. If I use the cache for that purpose, then I lose
track of =
the=20
set of patches I'm working with everytime (what if they don't have a
cohere=
nt=20
naming?)
I see a similar problem with unapply. What is the reason to
preserve =20
the patch in _darcs/patches if I do not have a way to inspect it?
Also =20
what is the reason to preserve it in _darcs/patches if it is
preserved =20
in the cache anyway? Maybe there is something obvious I'm missing,
but =20
the description I red didn't mention anything about this. Even if =20
there is a way to inspect the patches, how do these commands
improve =20
over the existing obliterate + patch preserved in the cache.
They allow the user to be unaware of the cache (or not to have one).
The=20
patches are given to you in a named bundle. That way, you keep them
togethe=
r=20
for later use. For instance, suppose you implement some feature in a
serie =
of=20
10 patches. Then you realize that it has a problem which makes the
feature=
=20
undesirable for the moment (say, you have to wait for a new version
of libf=
oo=20
so that some function there is fixed before your feature works at
all). You=
can=20
then unapply the 10 patches to get a feature-waiting-for-
libfoo.dpatch bund=
le.=20
You keep this bundle and apply it whenever libfoo2 gets released.
Without=20
unapply, you need to keep a full repository feature-waiting-for-
libfoo. You=
=20
might even want a repository without-feature-waiting-for-libfoo so
that you=
=20
can use pull --complement to get exactly the right set of patches.
That's t=
wo=20
full repositories versus a bundle with 10 patches. Another example
would be=
if=20
you wanted to keep the patches for reference, for example as an
explanation=
as=20
to why some thing is not doable. In that case too, it saves you from
keepin=
g=20
two repositories, and the bundle shows you where exactly the problem
is (ju=
st=20
open it in your text-editor).
What I would really find useful however would be a darcs diff --
patch =20
"title" remote-repo, i.e. a way to see a patch that is in a remote
=20
repository. I prefer diff over whatsnew or changes --verbose,
because =20
I can get a unified or context diff that shows me the context
around =20
the change. whatsnew or changes --verbose are harder to read in the
=20
context. darcs changes already can do this with the --repo
argument. =20
So maybe if we could add the --repo argument to diff then we would
get =20
the ability to check remote patches and something like fetch/
unapply =20
may become unnecessary.
I think these are orthogonal, and we should try to make changes -i a
supers=
et=20
of diff in that case.
P.S. keep in mind that I say all this because I do not see any
obvious =20
use for these two commands, that I cannot already do using the
cache. =20
Maybe I'm just missing the obvious.
Note also that these commands allow the user to be unaware of the
cache, wh=
ich=20
is a good thing. The cache is currently overloaded between download-
speed=20
improvement and a collection of unapplied patches. This means that
erasing =
the=20
cache can destroy valuable information, which is not what a cache is
suppos=
ed=20
to do. If you use fetch and unapply consistently rather than relying
on the=
=20
cache, then you can always get rid of your cache, should you need
to. There=
's=20
no reason I should have to keep every patch i have ever downloaded,
so that=
I=20
can keep some patches which I do not want to see applied yet.
Hope this helps,
=46lorent
--nextPart1323724.XxME5LlBlx
Content-Type: application/pgp-signature; name=signature.asc
Content-Description: This is a digitally signed message part.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
iEYEABECAAYFAksL/J0ACgkQTCPcDztjGo7eogCeMeaTDT5pUn0DXqqEKTEi9jtt
aCQAn2X/UpncO4+G9t1CIi5vh98+Ubv/
=Jo+M
-----END PGP SIGNATURE-----
--nextPart1323724.XxME5LlBlx--
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
--
Dan
_______________________________________________
darcs-users mailing list
[email protected]
http://lists.osuosl.org/mailman/listinfo/darcs-users
