[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
AW: [cdt-dev] difficulty creating a patch (!)
|
Hi Andrew,
I have experienced similar problems but I could always fix
them by converting the line delimiters (from the eclipse File
menu).
Norbert
hi Bogdan, Sunil,
thanks for the responses. I do
understand synchronization/update-to-dateness issues however, and have
eliminated this possibility early on. I'm seeing the same problem today. I can
reliably do the following
1) download eclipse-SDK-3.1-win32.zip from eclipse.org, and
unzip it, chooseing a new empty location as the workspace
3) checkout as project,
the org.eclipse.cdt.managedbuilder.core plugin, from
HEAD
4) make a single character change to GnuMakefileGenerator
(and save)
5) do a Team
-> Create Patch
6) observe the patch consists of the every line of the
original being removed, every line of the slightly edited file being
added
In my
experience, this would normally point to line endings, but I believe I've
eliminated this also.
It'd
be great if anyone can confirm that the sequence above does or does not work for
them. (I've been using eclipse and cvs for a couple of years so am fairly
confident this isn't user error at this stage)
thanks,
Andrew
Andrew -
I just quickly took a look at the two files that
you mention at the bottom of your posting. IManagedScannerInfoCollector.java
hasn't been changed since last June while GnuMakefileGenerator.java was changed
yesterday (and if you take a look at the comparison, it is quite a big change).
To ensure successful patching, you have to make sure that your changes are
merged in with the latest from HEAD. To do this, perform a synchronize, and
merge all incoming changes with your changes. Once your workspace is up to date
with the latest from HEAD, you should have no problems creating a patch.
Regards,
Bogdan
First I
replaced the file with latest from Head, made the changes and created a patch.
FYI, I saw this strange behaviour with Eclipse v3.2 M5 and latest cdt
sources.
"Andrew Ferguson"
<Andrew.Ferguson@xxxxxxx>
Sent by: cdt-dev-bounces@xxxxxxxxxxx
02/28/2006 01:49 PM
|
Please respond
to
"CDT General developers list."
<cdt-dev@xxxxxxxxxxx> |
|
|
To
| <cdt-dev@xxxxxxxxxxx>
|
|
cc
|
|
|
Subject
| [cdt-dev] difficulty
creating a patch (!) |
|
hi, I'm having a lot of trouble creating a patch for some changes I'd
like to contribute and am wondering if other people have seen this or can
reproduce it. The summary is that Team -> Create patch is behaving as though the
entire file has changed, and have tested a number of things myself and was
hoping other people could say if they have seen this, or can see it. (Gory
details at end of email) Some files from within the same plug-in behave differently
when creating patches of single line changes. This seems to correlate with the
CVS Base time stamp - i.e. trying to create a patch against recently modified
files fails, while creating patches against older files (e.g. from Nov 2005)
succeeds. Has
any CVS repository reconfiguration occurred recently that could possibly explain
this? thanks, Andrew I'm using Eclipse 3.1 release,
and have checked out projects from dev.eclipse.org/cvsroot/tools as anonymous.
I'm running under Windows XP SP2.
If I create a one line change, and Compare or
Synchronize then I get a diff showing the single change as expected. However,
creating a patch creates a file consisting of the repository file and the local
file (prefixed by minus and plus symbols respectively). I've checked the following so
far * line endings (by saving
the local file with each type of line ending, including MacOS) * Compare shows that the
repository is using Windows line endings (other line endings show entire file
differences) * other whitespace
changes (i.e. indentation). * whether the local file is marked as binary (its ASCII
-kkv) * the version of eclipse
(this seems to happen under 3.1 and 3.2) * playing with the patch creation options. They produce
different formats but all think the entire file has changed. * file encoding is on default (Cp1252)
* the eclipse bug database doesn't
mention anything obviously related
* changing Window -> Preferences -> General -> Compare/Patch
-> Ignore whitespace to be on or off
The first few lines of the erroneous patch are
included at the end of the mail. I've noticed there are two paths in under
dev.eclipse.org that CDT is available from but these seem to be aliases.
To me, this
suggests that maybe something in the cvs repository is causing this, but I can't
see how? I've
tried going back to square one with a fresh eclipse installation etc.. and am
not having any joy. (The same setup worked previously). Other people within ARM
can reproduce this, so I'm wondering can anyone else on this list reproduce
it? Strangely,
I see this behave correctly for some files. For example,
C:\Eclipse\CDT-DEV-HEAD\workspace\org.eclipse.cdt.managedbuilder.core\src\org\eclipse\cdt\managedbuilder\scannerconfig\IManagedScannerInfoCollector.java
will generate correct single line patch files.
While
C:\Eclipse\CDT-DEV-HEAD\workspace\org.eclipse.cdt.managedbuilder.core\src\org\eclipse\cdt\managedbuilder\makegen\gnu\GnuMakefileGenerator.java
will generate an entire-file-changed patch.
Files that generate
correct patches have Properties -> CVS -> Base time stamp occuring earlier
than February 2006
-- IMPORTANT NOTICE: The contents of this email and
any attachments are confidential and may also be privileged. If you are not the
intended recipient, please notify the sender immediately and do not disclose the
contents to any other person, use it for any purpose, or store or copy the
information in any medium. Thank you._______________________________________________
cdt-dev mailing
list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
-- IMPORTANT NOTICE: The contents of this
email and any attachments are confidential and may also be privileged. If you
are not the intended recipient, please notify the sender immediately and do not
disclose the contents to any other person, use it for any purpose, or store or
copy the information in any medium. Thank you.
