Jesse Erlbaum wrote:
> In this situation, svn seems to force the developer to make arbitrary
> decisions on very meaningless topics. A "branches" directory? You
> mean I can't have branches without a directory? The feature just
> goes away? That doesn't sound right to me.
Perhaps because it isn't. Standard usage is to have a "branches"
directory, but that's just a name; it doesn't mean anything to
subversion. You could just as easily break your repository into "prod",
"test", and "dev" if you wanted, and if that fit your project
requirements better. (I'm actually working on several projects like
that, where we don't have official version releases; we just migrate
code to production as it is completed.)
> Devising a directory taxonomy for this purpose seems contrived. The
> capability to branch and tag are present all the time -- not just when
> you create a particular directory for the purpose. Features should
> not go away just because I failed to create a "magic directory".
> IMHO. (And what if I decide I need to tag something which I didn't
> plan on tagging when the project started? Am I just screwed?)
No, you're not--and again, there's no such thing as a "magic directory"
in subversion. They're all the same to the server; it's the users who
assign special meaning. Adding branching/tagging to a repository where
you didn't plan for it originally can be a bother, since you need to
create a new set of top-level directories and copy the appropriate
sources into them, and then switch all of the existing working copies to
point to the appropriate new subdirectory, but that's why it's
recommended standard practice to create a set of top-level folders like
that when you create the repository. Once you've done that, branching
and tagging are easy.
> And, let me say this: I would like to hear the arguments in favor of
> the Subversion way. I am a newbie, and suspect that when I learn "Tao
> Svn" these questions will appear as they are: The result of the
> switch between two similar but philosophically divergent systems.
One major benefit (to me) is the ability to continue to tweak a tag
after it's created. In my previous job, I'd tag code once I felt it was
ready for QA; any bugs that were subsequently found would require me to
"force" the tag to update. With subversion, it's much easier--just
update the code in the specific tag directory. Bang. Done. Oh, and
merge the changes back into the main development branch. I'm sure
others have other reasons.
> Question: How does this effect the command line for checkout? For
> that matter, what is the purpose of the "project" in the follow
> example checkout command?:
>
> svn checkout file:///path/to/repos/trunk project
>
> Is that just the name of the directory into which the files in the
> selected repository path will be checked out?
Yes. So, depending on your layout, you'll want something along the
lines of:
svn checkout file:///path/to/repos/trunk/project1 project1_dev
or
svn checkout file:///path/to/repos/project1/trunk project1_dev
where project1_dev is simply where you want your working copy to be.
It's optional, if you want to keep the name of the bottom-most
subdirectory, but I've found that I generally want a different name.
'trunk' isn't very descriptive. :-)
-David (former CVS junkie)
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Mon Nov 7 22:24:40 2005