Announcing test svn import

[Thiago Macieira]

Matt Rogers wrote:
>we may want to keep the external there. when you checkout kdelibs, it
> looks like you get an unresolved symlink unless you also checkout
> kde-common/admin.
>
>is this the way we want it or do we want behavior compatibility with
> cvs?

IMO, the symlink is a better alternative. It forces the checkout of 
kde-common, but that's the least of the problems. As I see it:

Advantages of symlink over svn:external:
- consistent admin dir -- no uncommited stuff in one module but not in 
others
- simpler to set and use
- no hassle with anon mirrors (which would either require anonymous access 
to our main server, or rewriting the property [which would in turn mean 
that the mirrors aren't exact copies!])

Advantages of svn:external over symlink:
- no problems on platforms that do not support symlinks (think Windows 
clients) or older Subversion clients (<= 1.0)
- no need to remember to checkout and to update kde-common

Branching will be a problem in either solution. With symlinks, the 
branches or tags external to /branches/KDE will either have to branch 
kde-common, or update the symlink to point to kde-common somewhere else. 
With externals, the properties on each dir would have to be updated to 
match the URL of the suitable branched kde-common.

-- 
  Thiago Macieira  -  thiago (AT) macieira (DOT) info
    PGP/GPG: 0x6EF45358; fingerprint:
    E067 918B B660 DBD1 105C  966C 33F5 F005 6EF4 5358

3. Ac seo woruld wearð geborod, swá se Scieppend cweað "Gewurde Unix" and 
wundor fremede and him "Unix" genemned, þæt is se rihtendgesamnung.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20050218/a1f370c9/attachment.sig>