> -----Original Message-----
> From: Talden [mailto:talden@gmail.com]
> Perhaps we're all guilty of trying to educate in proper procedure
> rather than solving the immediate problem at hand
I would say, some are guilty of not being clear that that is what they
are trying to do, giving the impression that they did not properly
understand the OP's question. I got that impression so it seems likely
that others got that impression too.
As in the other poster's analogy, the 'helpful local' says "I would not
start from here to get to Hiddenton" but could instead say "You have
come the wrong way, now you need to go back the way you came, and then
take the other road to Hiddenton, next time you might like to use a map
before setting out."
If the user really wants to fix the existing project to conform with a
recommended layout, then perahps use of dump and dumpfilter could be
used. The only time I used it myself, was also at the beginning of my
svn use, to fix up some wrongheaded layouts, But that was in the import
of a large existing project that had previously been in CVS for years
and had lots of branches, tags, and especially errors. If it's just
started, it may indeed be easier to just restart.
I usally like to have the 'trunk' version be the latest stable, thus
developing on a 'branch' and subsequently merging (usually not using svn
merge), also I would not create the subdir trunk/test/ in Jfk's example,
I would place the files directly in trunk/ , because I use one trunk per
project within a repository:
Programs/prog1/trunk
Programs/prog1/branches/branch1
Programs/prog1/branches/branch2 etc.
Programs/prog2/trunk
And so on. I think this is described as one common choice in the book
and corresponds conceptually with how CVS works. But, other people do it
a bit differently as described in the book and as I have seen on some
project websites. SVN is good in that it allows such flexibility, but,
it's true that some of the tried-and-true layout strategies have evolved
for good reason.
I think it does not make so much difference for a single-user
repository. So long as you actaully CHECK IN your own changes somewhere!
I also understand that it is very difficult to actually 'corrupt' your
code by ordinary svn commands, that is the whole point of the system.
'Dangerous' commands are mostly in the svnadmin interface not the
ordinary svn.So the worst effect should be a sort of 'weird' history at
the beginning of the project. Lots of projects have that! The
aforementioned large project begain life using plain RCS for revision
control and then ported to CVS, then recovered after a serious machine
failure in which some branch-roots fell through the between-hard-backups
cracks, then ported to SVN, so there's lots of wierdness and it mostly
doesn't bother us. So far we have been able to identify the correct
exact version that was used for so-and-so's PhD thesis when necessary,
that's the main thing, and to enable this the main point is to check-in
the version before doing the actual project that uses the software
regardless of the layout.
Enough lecture.
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org
Received on Fri Sep 28 15:58:56 2007