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 [EMAIL PROTECTED] _______________________________________________ gnucash-devel mailing list [email protected] https://lists.gnucash.org/mailman/listinfo/gnucash-devel
