[boost] Re: Steps before moving to Subversion

From: Robert Mathews (rmathews_at_[hidden])
Date: 2005-04-25 09:20:12

"Russell Hind" <rh_gmane_at_[hidden]> wrote in message
news:d4a78b$dfm$1_at_sea.gmane.org...
> Robert Mathews wrote:
> >
> > 1) svn:externals.
> > We used svn:externals to replace SourceSafe's concept of "shared files".
> > However, svn:externals are bad because
> > - commits at the top of a tree that contains externals do not propogate
> > through the externals. So, if you have a large tree, some parts that are
> > externals and some that are not, and you've made changes all over, when
you
> > commit you have to remember to visit every single external and then
commit
> > there as well.
> > - branching and tagging doesn't do anything special with svn:externals,
and
> > you'd want it to.
> >
>
> We use svn:externals for the same reason and I understand the problems
> too.  From the svn bug reports it looks like they are working on
> 'relative' externals which will then be known to be in the same
> repository and can therefore be commited in one go.

Right - that's another problem (for now) with them that I forgot to
mention - all svn:externals are absolute pathnames, so that you have to hard
code in the name of the server where the externals are. This means that if
you were to rename your server, all of the svn:externals would be broken.

>
> This will also bring in extra flags for externals to say whether to copy
> the external on a branch/tag or to mark it for the current revision etc.

That'll be nice.

>
> This should address what you need (and we) need, but I've no idea when
> this functionality will be completed.  Might be worth searching their
> mailing list/bug reports for more info.
>
> >
> > 3) berkley-DB repository speed.
> > It's slow to do common operations like fetching new files and getting
> > history. You might want to consider using the new native file format
FSFS,
> > as it is faster.
> >
>
> FSFS is faster for a lot of things, but not for a checkout of HEAD.
> Read the docs as they explain that the FSFS repo format stores diffs
> from the previous revision so to build up the HEAD revision, it has to
> go back to the start the slowly build up the changes.
>
> We changed our repo from a BDB to an FSFS with 1.1.4 when a few more
> issues seemed to have been cleared up, mainly because it allows us to
> use rsync to back it up to another server as each revision is just a
> file, rather than having to do a hotcopy of the entire db file.  FSFS is
>   quicker for other operations, and are much smaller in our experience.
>
> >
> > We also used TortoiseSVN to replace the SourceSafe explorer. It's very
slow,
> > and I've basically stopped using it except for the merge dialog.
> >
>
> Turn of 'recurse into folders to fetch status' in the 'look and feel'
> tab of TSVN options.  That will dramatically increase its speed.

Sure, then it's dramatically faster, but also doesn't tell you if a folder
contains a subfolder that has changes that need committing .. couple that
feature with the need to visit each externals folder individually when doing
commits, and you've got a situation where you're likely forget to check some
code in.

>
> I've come from VSS too, and there isn't a single feature of VSS that I
> miss now I've been using subversion and TSVN for over a year.

No, no, please don't get the idea that I was *missing* VSS for a single
moment. Only that when the folks at boost design their repository, they'll
want to minimize the number of externals they use, and that they'll want to
watch out for the '--non-recursive' flag.

>
> > I can't comment on the dysfunctional merge issue - I've used the merge
> > feature, and I've not lost any work with it yet.
> >
>
> I use merge and have had no issues with it.
>
> Cheers
>
> Russell
>
> _______________________________________________
> Unsubscribe & other changes:
http://lists.boost.org/mailman/listinfo.cgi/boost
>