[Gnucash-changes] r13272 - gnucash/branches/cashutil - Halting the cashutil branch until further notice - development continues outside svn

Josh Sled jsled at asynchronous.org
Wed Feb 15 19:44:06 EST 2006


On Thu, 2006-02-16 at 00:15 +0000, Neil Williams wrote:
> No-one here probably believes me, but IMHO it's actually easier to use CVS, 
> makepatch and manifest files rather than svn merge. Why? Because I don't have 
> to keep track of arbitrary numbers that are outside my control. r numbers may 
> be the bees knees to others here but I just wish that trunk/ had separate r 
> numbers for a branch and that different trees had their own r sequence, not a 
> single sequential number for the entire repository. It perturbs me each time 
> a commit to htdocs increments the revision number for trunk. Completely 
> bizarre in my book. We'll have r numbers in the tens of millions by the time 
> we get to gnucash3. With CVS and makepatch, I can script the entire process 
> and just get on with viewing the changes, before applying the entire patch in 
> a single operation.

SVN only has a single revision number -- that of the repository.  We
could have made seperate repositories for each of the htdocs,
gnucash-docs and meta "module[s]"... but, the reasoning goes: why have 4
different repositories where one would suffice?

I don't understand why you need to keep track of any more than 1 number
-- that of revision at which point you branched.  And I don't see why
that can't be in a comment, as the SVN docs suggest.  Frankly, I don't
understand why you're doing any merges at all...?


I think a CLI front-end is a valuable (future) addition to gnucash, and
I think cashutil should be part of the gnucash source tree ... in fact,
using the same translations and build system.  It's just another
front-end...  `./configure --enable-cli --disable-gtk` ... is it not?

-- 
...jsled
http://asynchronous.org/ - `a=jsled; b=asynchronous.org; echo ${a}@${b}`


More information about the gnucash-devel mailing list