Announcing test svn import

[Thiago Macieira]

Cornelius Schumacher wrote:
>- I would prefer /trunk/core over /trunk/KDE. KDE is more than the core
>modules after all.

Makes sense.

Do you think /branches/KDE should be renamed /branches/core as well? The 
sole reason I thought of /trunk/KDE was to keep the name in both areas.

But, then again, since we won't have a /branches/extragear 
or /branches/playground, it doesn't matter.

>- I don't really see the need for a "work" directory, separating between
>temporary and released branches seems to be a bit artificial. A
>temporary branch will disappear when it isn't needed anymore in any
>case, so it won't clutter the directory it's in, be it "branches" or
>something else.

Okay. As I said, "work" was an invention of mine. I don't know anyone who 
uses that.

I thought of it after taking a look at /branches before I started moving 
things around. Granted, there were a lot of superfluous branches there, 
but even listing the directory was slow.

Take a look: https://svn.kde.org/viewcvs/branches/?rev=343811

>- Branches should probably include one or several subdirectories named
>after the project. So it isn't needed to come up with super-creative
>branch names. kwebdev/quanta/make-it-cool sounds fine to me.

I don't like the idea of generic branch names for two reasons, but I won't 
intrude in other projects' decisions:

1) it tells nothing about what the branch is, except for those who agreed 
to create it
2) reutilisation of the same name

#1 isn't an issue if no-one but the maintainers is supposed to be using 
that branch.
#2 isn't really an issue in Subversion, since names can be reused again 
and again.

>- "tags" shouldn't be named "releases". There are lots of tags which
>don't correspond to a release, but just identify some kind of snapshot.

True, but not many people use tags. They just remember the last revision 
they merged stuff. Since it's now a global value, it's much easier to 
remember than to find out each individual file's revision.

You can use properties for that too (that's how svnmerge works anyways).

>A "releases" subdirectory in "tags" might make sense, though.

/tags/releases/KDE/4.0 sounds a bit long for me. Same thing 
for /trunk/playground/artwork/plastik2 
or /trunk/extragear/multimedia/k3b/src.

I'd much rather see people use "tags" inside /work than /releases.

Out of curiosity, here's how the Samba Subversion repository is layed out 
(http://websvn.samba.org/cgi-bin/viewcvs.cgi/):

/
branches/
  SAMBA_2_2/
  SAMBA_2_2_RELEASE/
  SAMBA_3_0/
  SAMBA_3_0_RELEASE/
  SAMBA_3_1_RELEASE/
  SAMBA_4_0/
  tmp/
    SAMBA_3_2_MERGE/
    ...
hooks/
tags/
  ...
  release-2-2-10/
  release-2-2-11/
  release-2-2-12/
  ...
test/
trunk/
  docs/
  examples/
  ...
  source/
  ...

Remember that's one repository for a single program. For KDE, we're 
talking about lots of programs being released, from the same repository.

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

5. Swa he géanhwearf tó timbran, and hwonne he cóm, lá! Unix cwæð "Hello, 
World". Ǽfre ǽghwilc wæs glæd and seo woruld wæs fréo.
-------------- 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/20050220/d3dfe7a0/attachment.sig>