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

Re: Recommended Subversion Repository Structure

From: Jay Lessik <joemama77ca_at_yahoo.ca>
Date: 2006-03-24 20:35:22 CET

-- SNIP --

The thing to be aware of is that, at least until SVN
> supports true renames, reorganizing your repository
is
painful--anyone
> who has checked out your code may need to delete
their working copies
> and re-checkout, especially if they've been working
on a moved file.

They won't have to delete their working copies, they
can just use svn
switch to point to the new location.

And I don't believe that supporting true renames will
make the re-org
any less or more painful, the developers will still
need to switch
their working copies over to the new location.

-- SNIP --

That brings up an interesting question... Right now
our repository doesn't have any trunk, branch, or tag
directories... just a bunch of projects... I assumed
that I could just create the trunk, branch, and tag
directories under each project, then use svn move (I
use tortoisesvn) to move the files from the root of
the project into the trunk directory... But what
happens if some developers have the code checked out
and have modifications on their local machines? If
they point to the new location (project/trunk) then it
should commit properly, right? Since the path is the
same relative to trunk?

Thanks for all the help, I really appreciate it...

--- Blair Zajac <blair@orcaware.com> wrote:

>
> On Mar 24, 2006, at 8:33 AM, Gale, David wrote:
>
> > Jay Lessik wrote:
> >> I'm new to subversion so forgive me if this
> question
> >> is newbie-ish...
> >>
> >> I know that project repository structure has been
> >> discussed on this list and I've read a lot of the
> >> posts, but I wasn't able to find a clear answer
> to the
> >> question of which of the following is better?
> >>
> >> repository/
> >> projectA/
> >> trunk/
> >> branches/
> >> tags/
> >> projectB/
> >> trunk/
> >> branches/
> >> tags/
> >>
> >> OR...
> >>
> >> repository/
> >> trunk/
> >> projectA/
> >> projectB/
> >> branches/
> >> projectA/
> >> projectB/
> >> tags/
> >> projectA/
> >> projectB/
> >>
> >> The documentation recommends the first structure
> as do
> >> a lot of other sites and people on this list, but
> this
> >> post
> >>
>
(http://svn.haxx.se/users/archive-2005-04/1870.shtml)
> >> seems to recommend the second structure and lists
> some
> >> good reasons... Would using the second structure
> >> cause problems down the road? I don't want to
> have to
> >> reorganize my repository later when I find out I
> can't
> >> do something or something isn't working
> properly...
> >
> > They both work, and both allow (roughly) the same
> reorganization
> > possibilities. The thing to be aware of is that,
> at least until SVN
> > supports true renames, reorganizing your
> repository is painful--anyone
> > who has checked out your code may need to delete
> their working copies
> > and re-checkout, especially if they've been
> working on a moved file.
>
> They won't have to delete their working copies, they
> can just use svn
> switch to point to the new location.
>
> And I don't believe that supporting true renames
> will make the re-org
> any less or more painful, the developers will still
> need to switch
> their working copies over to the new location.
>
> >
> > Personally, I'd examine how closely ProjectA and
> ProjectB are related;
> > if they're not at all, consider setting up two
> repositories (one for
> > each). Short of that, I'd tend to go with the
> second repository model
> > (repos/{trunk/tags/branches}/{project...}), as
> that's clearer to me,
> > though the distinction is small; one of the few
> instances where it'll
> > come up is checkouts:
> >
> > svn co <repos>/trunk/projA
> > ...creates a directory named "projA", whereas
> > svn co <repos>/projA/trunk
> > ...creates a directory named "trunk", which is
> hardly helpful.
> > Especially since you can then switch it to a
> branch directory, and
> > confuse everyone. Of course, you can get around
> this by always
> > explicitly setting a directory name, but why
> bother?
>
> That's just a naming issue. One many of the
> projects I work on, we
> have per-user branches and a trunk where users merge
> their work
> into. So you end up having a directory containing
> working copies
> named like this:
>
> $ ls
> projecta-branch
> projecta-trunk
> projectb-branch
> projectb-trunk
>
> Here it's implied that the branch is my per-user
> branch.
>
> So you'll have to specify the directory to check out
> into anyway.
>
> So I still recommend that you have the
> project/{trunk,tags,branches}
> structure.
>
> Regards,
> Blair
>
> --
> Blair Zajac, Ph.D.
> <blair@orcaware.com>
> Subversion training, consulting and support
> http://www.orcaware.com/svn/
>
>
>

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Mar 24 20:36:41 2006

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.