OK! This is starting to come together in my poor, overworked mind. I'm
leaning towards one single repository with many projects inside it.
Each project contains the typical trunk, branches. So for Project1
under trunk, I'd have all of my typical directories (build, doc,
install, etc.).
If I decide to branch from there (say for a new version of the same
Project with specific changes) I'd copy everything from the trunk to a
branch directory and name that branch something useful.
If I have completed, releasable (or testable) version I'd copy that to
the tags directory with a useful name that I could track myself. So,
under tags\ I might have Release 1.0.1 and Release 1.0.2, etc or Testing
1.0.1, Testing 1.0.5001, etc. I name these myself and I'd know what's
next because I'm naming these manually.
Am I close?
> -----Original Message-----
> From: cmpilato@virt16g.secure-wi.com [mailto:cmpilato@virt16g.secure-
> wi.com] On Behalf Of C. Michael Pilato
> Sent: Thursday, March 25, 2004 11:20 AM
> To: Crucius, Wesley
> Cc: users@subversion.tigris.org; bbeaudet@efficiencylab.com
> Subject: Re: Repository Layout - One Vs. Many
>
> "Crucius, Wesley" <WCrucius@sandc.com> writes:
>
> > I'm still struggling with this one myself. I understand your
> explaination
> > and I can accept it completely. I just want a way to be able to go
to
> the
> > repository and get the svn revision that "is" release version XX.YYY
of
> my
> > application.
>
> Dude, that's what tags are for. See http://svn.collab.net/repos/svn/
> for examples.
>
> > I don't want want to have to maintain a cross-reference list
> > independently of svn, and tagging seems to be problemmatic for
> > TortoiseSVN because it really slows down explorer with, for example,
> > 6 projects and a total of around 200 tagged revisions.
>
> Is that because you actually have all 200 of those tags on your local
> disk? If so -- don't do that! :-)
>
> > So I thought maybe a label property that manually gets set prior to
> > commits of what would be release versions. The problem with this is
> > that there does not appear to be a way to determine what is the
> > revision number of a revision whoose label property has a value of
> > XX.YYY. Please help me out if I'm missing something... Maybe I'm
> > missing the most obvious solution here? Just put the release
> > version string in the commit message????
>
> You could do that if you had to. I mean, if revision 4589 was the
> revision that solidified your product's version 2.01, you could
> retroactively
> change 4589's log message to have some greppable string:
>
> RELEASE-TAG: ProductName Version MM.mm.pp
>
> But seriously, it sounds like your real problem is that some element
> of your workflow, combined with some performance issues with
> TortoiseSVN and/or Subversion, is keeping you from doing The Right
> Thing.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Thu Mar 25 17:36:43 2004