[Gnucash-changes] r11623 - in gnucash/branches/cashutil/cashutil: [temp]

[Neil Williams]

On Tuesday 01 November 2005 12:38 am, you wrote:
> You DO realize that the SVN repository is going to be destroyed this
> weekend, right?

Absolutely. Hence the [temp] and [demo] suffixes to the commit logs.

I was following a tutorial and decided to make sure it worked.
:-)

Perfect opportunity and a chance for the code to see some light - briefly.

Actually, as far as the logs are concerned - did I get the branch operation 
right? It looked OK this end.

I thought afterwards whether a SVN equivalent to a CVS tag would be required 
to mark the point immediately before a new branch is created. I guess it is 
replaced by the revision number for the actual branch creation?

The code itself is real and working - what I didn't commit was the 
configure.in / autogen.sh linkage that builds the cashutil code from the top 
level ./autogen.sh process. So the cashutil code doesn't build in the branch 
but it would build on it's own. Still, that's by-the-by, it's a demo and it's 
intended to be deleted in due course. Besides, it illustrates using a branch 
with code that would break the main build if committed direct to the trunk.
:-)

> Just wanted to make sure you're not expecting these 
> commits to actualy stay...  Because they wont.

That's just as well!

Honestly, this was my express purpose - to put a "real" example against the 
demo repository and make sure it worked with more than just test data.

All the cashutil code is safely ensconced in my local CVS - I'll make a real 
branch once the conversion is complete.

I was quite pleased to find, for example, that when I add an entire directory, 
SVN adds all the relevant files WITHIN that directory AND recursively for 
each subdirectory.

That was a PITA with CVS - add the directory and then individually specify 
each file within that directory with a cvs add then move down to any 
subdirectories. When you aren't importing an entirely fresh tree but instead 
adding a substantial amount of code to an existing tree, that can be 
frustrating. Yet another element of CVS branching that bites back. After all, 
what is the point of a branch if you aren't going to add / delete large 
sections of the codebase!

So far, I like SVN. It does deal with at least some problems within CVS 
without making it hard for users to convert from CVS usage. The server config 
seems fine. I would say that when new developers are given commit access to 
this repository, it would be a good idea to mention that the username may 
need to be specified in the svn checkout command - that caught me out 
initially.

svn+ssh://username@svn.gnucash.org/...

Apart from that, a quite painless transition. Has the issue with .cvsignore 
converting to svn:property been fixed too?

-- 

Neil Williams
=============
http://www.data-freedom.org/
http://www.nosoftwarepatents.com/
http://www.linux.codehelp.co.uk/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.gnucash.org/pipermail/gnucash-devel/attachments/20051101/84ea5227/attachment.bin