Quoting Neil Williams <[EMAIL PROTECTED]>:

On Monday 07 November 2005 4:36 pm, Christian Stimming wrote:
Neil Williams schrieb:
>>Is there any particular reason the libqof move wasn't /ONE/ changeset?
>
> To separate the Makefile.am changes from the simply copying of the files.
> I didn't want people to have to sift through a >1Mb diff to find what's
> been changed in configure.in or src/engine/Makefile.am so I committed
> those first.

Probably a bad idea to begin with. If people want to know the changes in
Makefile.am, they will use "svn diff Makefile.am".

Well, that's what someone asked for so that's what I tried to do.

Who asked for that?  I've asked for emailed-in patches to be small..
But who ever said that SVN commits should be small?  SVN commits
should be functionally-complete objects.

Please replace
the newly added files by the "svn move"d files.

I would if I had the originals.
:-(

As I said, my working copy tree was trashed half way through. I have no
originals.

svn checkout a new copy of the trunk branch?
svn revert?

OK, what I should have said was: I don't know what that is supposed to achieve
or how you meant me to use it.

What does it achieve? If it's a good idea, why assume that I know about it?
Shouldn't it be documented somewhere?

it prevents autogenerated files from getting into your source tree.
it lets you start a new "build from scratch" by running:

 rm -rf build-tree; mkdir build-tree; cd build-tree; lndir ../src-tree ;
 ./autogen.sh ; ./configure ; make ; make install

I've certainly mentioned this on the list NUMEROUS times.

These are the problems with the build - which haven't gone away by changing
the technology, the symptoms of the problem have just changed. I don't know
everything, I'm not party to the unwritten conventions of code management and
I make mistakes. Sorry. I'm trying to fix it but I need help with this!

I fouled up, OK? Now please stop shooting me and let's see how to fix it.

I don't think anyone is trying to shoot you.  I, at least, was trying to
understand why you did what you did to understand what was going through your
mind.  You might know something I don't...  Or you might have just been
confused in which case knowing what you were thinking could help in correcting
your misunderstandings.  I think we ALL are just trying to help you fix it.

For example, you could just revert your tree to the revision before your changes
or even revert the repository to the previous revision.  (This is yet another
reason to have fuctionally-complete commits -- makes it easier to migrate or
revert changesets).

-derek


--
      Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
      Member, MIT Student Information Processing Board  (SIPB)
      URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
      [EMAIL PROTECTED]                        PGP key available

_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel

Reply via email to