On 5/30/05, Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Saturday 28 May 2005 11:13, jerome lacoste wrote:
> > Now some notes. I just started to use quilt this week. I am using it
> > to manage local patches
> >
> > - removing patches
> >
> > One of the patches I had applied locally has been merged upstream.
> > I made a cvs up on the code with my patches applied and this created
> > an issue. I think I've also refreshed my patch later on, I thought
> > that this would make the patch 'empty'. Except that this created a
> > reverse patch!
> > I guess I shouldn't have poped all patches first, do a cvs up and push
> > them afterwards, removing the obsolete ones.
>
> The right thing to do would be:
> - pop all patches
> - cvs up
> - push all patches again, merge rejects, and remove patches which have
> meanwhile been integrated.
So we agree :)
> > Am I correct? If so, maybe the documentation (PDF) should contain some
> > notes about merging upstream patches.
>
> Yes, I agree. Do you want to write something up and send a patch?
Here's one. Let me know if it's too verbose.
> > - Furthermore It took me time to understand that in order to get a new
> > file into a patch, I had to do something like
> >
> > touch myfile
> > quilt add myfile
> > cp myfile/from/somewhere myfile
> > quilt refresh
> >
> > Without creating the empty file first and adding it, quilt was not
> > doing anything.
>
> Wrong order of operations. Do it like this:
> - quilt add myfile
> - cp myfile/from/somewhere myfile .
> - quilt refresh
So you don't need the touch command...
OK I tried again on a simple example but this time it worked. It's
strange because I was sure. I had done the same operations. I probably
didn't.
> > [..
> > I understand why it's like that now, but I wonder if the doc could be
> > more explicit about it
>
> Hmm, the documentation says:
>
> > [...] Files must be added to a patch with quilt add before they are
> modified. Note that this is slightly different from the CVS style of
> interaction: with CVS, files are in the repository, and adding them before
> committing (but after modifying them) is enough. [...]
>
> How do you want this to be explained instead?
It's OK. In my experience and probably because of my mistake, I've had
to touch the file before quilt adding it.
But if it works without, nothing is to be changed.
Jerome
? doc/cmbx12.log
? doc/cmsltt10.log
? doc/missfont.log
Index: doc/main.tex
===================================================================
RCS file: /cvsroot/quilt/quilt/doc/main.tex,v
retrieving revision 1.13
diff -u -r1.13 main.tex
--- doc/main.tex 8 May 2005 17:43:58 -0000 1.13
+++ doc/main.tex 30 May 2005 15:26:35 -0000
@@ -516,6 +516,44 @@
} and then applying the patch to the working tree. The \quilt{fold}
command combines these steps.
+\subsection{Sharing your patches}
+
+You may sometimes need to share your patches with someone else, or
+reapply them on another instance of your software. As quilt patches are all
+contained in the \textsf{patches} directory, sharing your patches is a
+very simple operation. Make sure your patches are all up to date using
+\quilt{refresh}, and distribute the contents of your patches directory.
+
+\subsection{Merging with upstream}
+
+The concept of merging your patches with upstream is identical to applying
+your patches on a more recent version of the software.
+
+First make sure that your original patches are all up to date using
+\quilt{refresh}.
+
+Then if you start in a new directory, retrieve the new version of the sofwtare,
+(e.g. extract it from an archive or retrieve it from a remote source control
+repository) and copy your original \textsf{patches} directory inside this new
+directory. Otherwise, if you want to update your local version of the software
+using a source control client, you must first make sure your local tree is
+clean of your patches. You can ensure that by removing all patches using
+\quilt{pop -a} before applying the command that will update the local tree
+\footnote{
+ it's a mistake to merge your local changes using the source control
+ client. If you do that you will have a hard time updating your patches. In
+ that case, it's better to start from scratch and reapply your patches on a
+ new project.
+}. You can double check the clean state of your local tree using the diff tool
+that comes with your source control client.
+
+Finally apply your patches, either one by one or all at once using
+\quilt{push -a}. If nothing fails, you're done. Otherwise you will have to
clean
+up your patches. If one of your local patch was applied upstream, just remove
+it using \quilt{delete}. If there are conflicts betweem the new code and a
+local patch, you may need to rework your patches and \quilt{refresh} them one
+at a time.
+
\subsection{Forking}
\label{sec:forking}
Index: doc/quilt.pdf
===================================================================
RCS file: /cvsroot/quilt/quilt/doc/quilt.pdf,v
retrieving revision 1.7
diff -u -r1.7 quilt.pdf
Binary files /tmp/cvsgjXvZR and quilt.pdf differ
_______________________________________________
Quilt-dev mailing list
[email protected]
http://lists.nongnu.org/mailman/listinfo/quilt-dev
