> > > -----Original Message-----
> > > From: Tom Vergote [mailto:tom@tomvergote.be]
> >
> > > 1. Create a repository under the reporoot and import
> directory's for
> > > the projects? Where would trunks and branches be layed out? If I
> > > understand correctly with this setup a commit in proj1 for custA
> > > would updatethe revision for all projects in all customers.
> >
> > A commit is global to the repo, so yes, the revision will
> be increased
> > for all customers and projects for each change. Having global
> > revisions ticking away when there is no change feels
> strange to begin
> > with, but one get's used to it, and it becomes very handy
> to have each
> > change "tagged" with a revision.
>
> So you suggest tagging everything after a change instead of
> relying on the SVN revision numbers. My problem is that a lot
> of our projects are web applications, and the graphics and
> HTML designers need to use this source control too. They
> aren't always as technical as one would hope for and i'm
> trying to avoid all confusion.
No, I don't suggest that you tagg each change, I merely pointed out
that since each change results in a new revision that is global anyone
working in that repository will be able to refere to a specific change
by it's revision number without anyone needing to do any tagging.
In cvs this was not possible, you had to tag if you wanted to refer
to a specific point in time of the repo (well, unless you knew the time...).
Sorry for explaining so bad.
> > > 2. follow along the directory structure but create repositorys in
> > > each project, and then import trunk/tags/branches dir's in each
> > > projects repository.
> >
> > I'd stick with one repo. Projects and even customers may
> have stuff in
> > common, and having them in one repo makes it easier to make code
> > changes to many in one revision.
>
> Ah, you said something i was wondering about too.
> How are you supposed to (e.g.) use a dataaccess component in
> most of your projects, but still have the component as a
> seperate project (hmm, i hope i am clear here)
That depends on the demands on the external component. If you are
satisfied with incorporating new versions at a fairly slow rate then
I think you should handle it as a third party library. There was someone
who posted a pattern for that but I can't seem to find it. You might want
to search for it in the mail archives and look at this for the
functionallity:
http://www.cvshome.org/docs/manual/cvs-1.11.14/cvs_13.html#SEC104.
Otherwise if this library, if I may call it so, changes a lot you should
consider using svn:externals to incorporate it into your existing projects
as you see fit. Svn book reference:
http://svnbook.red-bean.com/svnbook/ch07s03.html.
> > Also proj1/trunk or trunk/proj1 that's difficult, maybe a matter of
> > taste? I think I'd do proj1/trunk, seems that would be more
> isolative
> > of the project. But it's easy enough to change if you
> decide it's not
> > the right way to do it. You would want tags and branches folders in
> > the same position as the trunk folder I would think.
>
> I haven't had the change to go through the svnbook so excuse
> me if i'm being ignorant, but is it really that easy to move
> repository's around? For example if you have a repository per
> project how would one go about moving it all into a new
> single huge repository.
You really should read it, it's an amazing piece of litterature :)
It's really that easy, as long as you are only using one repo you
would issue a few 'svn move' and you are done. svn book reference:
http://svnbook.red-bean.com/svnbook/re18.html
Also as far as I understand since there is no filesystem repo these
commands are not consuming loads of disk, they won't make your repo
slower and they are lightning-speed fast to issue.
/Nicke
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 15:53:31 2004