On Tue, 23 Mar 2004, Nicklas Norling wrote:
> > > > -----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.
No, it was my confusion, i'm still stuck in the wrong mindset when it
comes to revision control systems
>
> > > > 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.
>
Thanks for the link, i'll bookmark keep it in mind when i run into
something that should be solved this way
> 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.
Thanks this was obviously what I was looking for.
>
> > > 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 :)
I defenitely will, but i only had time to skim through it so far.
> 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
sweet, the more i learn about svn, the more i like it.
>
> 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
>
>
Thanks a lot for your patience
Tom
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Tue Mar 23 17:11:19 2004