[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Re: Build question

From: Robert Schneider <r.schneider_at_weingartner.com>
Date: 2005-11-07 15:59:35 CET

> -----Original Message-----
> From: Dimitri Papadopoulos-Orfanos [mailto:papadopo@shfj.cea.fr]
> Sent: Monday, November 07, 2005 3:23 PM
> To: users@subversion.tigris.org
> Subject: Re: Build question
> > I think this cannot be the proper way. If there are further items
> > shared differently to the special text box then this structure
> > work (Control A is used by project 1 and 2 and control B is used by
> > project 1 and 3).
> I don't understand why this wouldn't work. What do you mean exactly by
> "items that share differently to the special text box"?

You have suggested if the special text box is very closely
interconnected to the other projects then a single repository should be
used. But I think the client projects shouldn't be placed into one
repository just because they all use a special text box (which has only
some line of codes). Imagine if there would be another control that
might be used by one of those client projects but also by other ones
too. Should they also be placed into the repository now? Just because of
some little common controls (I called them items in the posting before)?
That's why I thought that this cannot be the proper way. Sorry for

> Anyway, it looks like the best solution would be to release each
> as an independent piece of software to be reused by other projects.
> Therefore that would be outside of the strict scope of Subversion.
> Subversion handles sources, you need a process to release your

I agree. And this would mean to use such a pattern that e.g. the control
would be build at first then the binary gets placed into the client
project repository which then gets built, right? And revision numbers
instead of HEAD should be used to fetch a certain state of the sources.

Don't answer if the mailing list is not the right place anymore to
discuss this.


To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 7 16:05:17 2005

This is an archived mail posted to the Subversion Users mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.