Thanks for all of your insights, and I will definitely take care from next
time on what I am doing. All your insightful thoughts were worth pondering.
Thanks to you all.
On 9/28/07, Atwood, Robert C <r.atwood@imperial.ac.uk> wrote:
>
>
>
> > -----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.
>
>
>
>
>
>
>
>
>
>
>
>
>
Received on Mon Oct 1 06:10:54 2007