"Brent R. Matzelle" <bmatzelle@yahoo.com> writes:
> > The Subversion project uses a log policy documented in our
> > HACKING file; or maybe you want to make up your own. Just avoid
> > ambiguous log messages -- choose some policy!
>
> I am not sure which one or ones your are referring to. I'll take a
> look.
Or just run 'svn log http://svn.collab.net/repos/svn', and scroll
through several pages. You'll see a pattern emerge. :-)
>
> > * EOL style: some of your source files seem to have CRLF
> > endings, and some just have LF endings. If you have a lot of
> > cross-platform developers, you probably want to set
> > 'svn:eol-style' to 'native' on everything. CVS does this by
> > default, but SVN does not. If you don't set this property, I >
> > > fear you're going to end up with a lot of flip-flopping of eol
> > > > styles in the future.... which means you won't be able to
> > see changes when you run 'svn diff'; the *entire* file will look
> > changed.
>
> That is a valid concern. Unix style it is then.
No, I'm not saying you have to force LF endings on everything. If you
set the 'svn:mime-type' property to 'native', then each file will
appear to have the "native" eol-style in each developer's operating
system. Win32 users will have working copies where every file has
CRLF line-endings, and Unix users will have working copies where every
file has LF line-endings. And these differences will be transparently
hidden when committing and updating.
> Saying that the Subversion client API is a moving target would be a
> great understatement. Just yesterday RapidSVN was building fine.
> Today yet another API change surfaced that prevents a clean compile.
> I want to be up to the minute as well but without a ChangeLog of API
> changes it is difficult to keep up to date. Maybe this process can
> be improved now that clients other than svn are dependent on the API?
We'll definitely freeze the API at some point. We already have a
policy document that defines forward- and backward- API compatibilty
issues... we just haven't started using it yet.
All I'm requesting is: if you sit down to work on rapidsvn, try
updating and recompiling svn first. Tweak rapidsvn to compile, make
your changes, and commit.
We could certainly keep a ChangeLog of API changes if it helps. But
normally, your compiler will make it screamingly clear exactly which
svn_ function has changed its signature. :-)
> > Anyway, looks like you guys are off to a good start. I hope this
> > feedback was useful!
>
> These are all good suggestions. As I said above, iteration of the
> code is a key here. Please keep the suggestions coming!
Cool, best of luck to y'all!
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Jul 30 05:47:46 2002