Re: [crossfire] Use of svn:externals in client code on SVN

2013-11-04 Thread Mark Wedel

On 11/ 4/13 04:41 PM, Kevin Zheng wrote:

Hi there,

Crossfire currently uses svn:externals to sync protocol definition
headers between the server and GTKv2 client. While this has its merits,
overall I believe it is confusing, cumbersome, and harmful.

 From the SVN Book [1]: "An externals definition is a mapping of a local
directory to the URL—and ideally a particular revision—of a versioned
directory. In Subversion, you declare externals definitions in groups
using the svn:externals property."

My guess is that the original intention of using them was to ensure that
the client protocol headers would always remain in sync with those in
the server. However, here are some issues:

  - The svn:externals property must still be modified manually
  - Copy/paste/merge is faster, less confusing, and works outside of SVN
  - Client sources locked to server, JXClient proves unnecessary

Further, there are several disadvantages to using them as well:

  - It only works with SVN - hinders future migration (if ever)
  - Confusing for people not familiar with SVN
  - Slow, try running `svn up` from the root and wait
  - Breaks `git svn`, which pacifies the impatient Git users

I propose that we go back to manually tracking the protocol headers
between the client and server. They are not updated that often, anyways,
and still need updating with the use of svn:externals. We can continue
using svn:externals in /latest, etc.

[1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html


 That is fine by me.  And before the externals was set up, my method of sync 
wast just a cp from one directory to the other.


___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire


[crossfire] Use of svn:externals in client code on SVN

2013-11-04 Thread Kevin Zheng
Hi there,

Crossfire currently uses svn:externals to sync protocol definition
headers between the server and GTKv2 client. While this has its merits,
overall I believe it is confusing, cumbersome, and harmful.

>From the SVN Book [1]: "An externals definition is a mapping of a local
directory to the URL—and ideally a particular revision—of a versioned
directory. In Subversion, you declare externals definitions in groups
using the svn:externals property."

My guess is that the original intention of using them was to ensure that
the client protocol headers would always remain in sync with those in
the server. However, here are some issues:

 - The svn:externals property must still be modified manually
 - Copy/paste/merge is faster, less confusing, and works outside of SVN
 - Client sources locked to server, JXClient proves unnecessary

Further, there are several disadvantages to using them as well:

 - It only works with SVN - hinders future migration (if ever)
 - Confusing for people not familiar with SVN
 - Slow, try running `svn up` from the root and wait
 - Breaks `git svn`, which pacifies the impatient Git users

I propose that we go back to manually tracking the protocol headers
between the client and server. They are not updated that often, anyways,
and still need updating with the use of svn:externals. We can continue
using svn:externals in /latest, etc.

[1] http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html

Thanks,
Kevin Zheng
___
crossfire mailing list
crossfire@metalforge.org
http://mailman.metalforge.org/mailman/listinfo/crossfire