>Your descriptions sounds something like the way one writes a Zope
>application. You create classes and subclasses within Zope's own code
>framework, and then 'register' your code as a 'product' within Zope.
>But a Zope product still lives in a subdirectory, so I've had no problem
>keeping my Zope product under version control; my Zope product
>directory also happens to be subversion working copy.
>
>
>
Yes, that's about the same...
>So if Expresso is like this, then you could do the same thing. There's
>no need to compare anything to 'vendor branching'. I don't think that
>term applies here at all.
>
>
Well, you could off course just pretend that there's no such thing as
vendor branching and just put everything in the thrunk (or only your own
sources and add that to expresso manually), but what happens then when
expresso releases a new version? Some kind of version branching would be
nice to keep track of this, that way it won't seem like I made the
changes, while it's just a new Expresso version (or you won't see a
change at all, if you don't put Expresso itself on svn).
And what happens if I discover a bug in Expresso? I might want to post a
bugfix and create diffs. This would be easier if there were vendor
branches.
Personally I've been thinking about keeping expresso in a seperate
branch, and then checking it out before i check out my own sources in
its subfolders. However, to use Expresso with Eclipse, I have to create
a Tomcat project in Eclipse and only copy specific folders into this
project. So if you put Expresso back on svn then, it will be totally
different.
The only solution I can think off is putting Expresso on svn, but export
it instead of checkin it out. That way I can only make changes to the
Expresso code if I check it out seperately. It's less convenient, but
better structured. The only thing I don't know is if SubClipse (the
svn-eclipse-plugin) can handle this, but I think it should be possible...
How does this idea sound to you?
Mark
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Wed Jul 14 15:46:48 2004