[openib-general] SVN deprecation

[Or Gerlitz]

On 1/4/07, Jeff Squyres <jsquyres at cisco.com> wrote:
> On Jan 4, 2007, at 6:20 AM, Or Gerlitz wrote:
>
> >> See "svn help <foo>" and the SVN book for more information.
> >
> > Considering myself as being located somewhere within the ~medium
> > range of the SVN users spectrum I truly think that my questions are
> > not of RTFM type.
>
> Sounds like you just don't want to read the fine documentation.  ;-)

I do want to read but (and forgive me if this seems like making you
work to explain me the manual) I also do want to double check that the
person that leads this process knows 100% what he is doing and for
that purpose i found it appropriate to ask you to review my suggested
work flow, anyway

>
> There's a nice overview of browsing a repository's history in the SVN
> book here:
>
>      http://svnbook.red-bean.com/en/1.2/svn-book.html#svn.tour.history
>
> > So let me see i can do it pro actively:
> >
> > assuming you have used the command
> >
> >       $ svn delete some-sub-tree-of-a-repository
>
> Actually, it would be:
>
> svn rm some-tree
> svn ci some-tree
>
> That would commit the removal of some-tree at the HEAD at repository
> number N.  Of course, one of the goals of SVN is to maintain an
> accurate history.  So you can always examine the repository at r(N-1)
> (or any prior values of N) to see what subtree looked like at exactly
> those points in time.
>
> Quoting the SVN book:
>
> "Of course, nothing is ever totally deleted from the repository—just
> from the HEAD of the repository. You can get back anything you delete
> by checking out (or updating your working copy) a revision earlier
> than the one in which you deleted it."
>
> > ***and*** left a README at the ancestor directory of this subtree
> > which
>
> Note that leaving a README in the directory has nothing to do with
> the semantics of how SVN works.  I think that this is probably
> obvious, but I just wanted to be precise.  :-)

It has to do with telling the user who just checked out the HEAD of
the repoistory at revision N what was the sub-tree/s **structure** at
the revision (which would NOT be N-1 if you don't do all  the delete
at once and even if you do all of them at once i am not sure it would
be N-1) which these trees where deleted.

> > says that you have just deleted sub-trees xxx,yyy,zzz etc my work
> > flow to get a checkout of xxx would look like:
> >
> >       $ svn co url/of/path/to/ancestor/directory
> >       $ cd /path/to/ancestor/directory
> >       $ read README, learn there was an xxx directory with content XXX
> >
> >       $ svn ls xxx -R
> > or
> >       $ svn co -r HEAD xxx
> > then
> >       $ cd xxx
>
> It's actually simpler than that:
>
>         $ svn co url/of/path/to/ancestor/directory
>         $ cd /path/to/ancestor/directory
>         $ read README, learn there was an xxx directory with content XXX
>         $ svn up -r N
>
> Which updates your current checkout to reflect the state of the
> repository (at that tree) at repository number N (where N is
> assumedly less than the value of N at the HEAD, so you're reverting
> back to an earlier state of the repository, before the stuff that you
> want was deleted).
>
> When navigating the history via "svn up -r N", there's a few complex
> corner cases where the update can fail (by design), but they aren't
> common and can be avoided by doing a fresh checkout of the r number
> that you want:
>
>         $ svn co -r N url/of/path/to/ancestor/directory

thanks for all the clarifications, the process you suggest seems fine to me.

Or.