Summary | Move to subversion for Horde code repository |
Queue | Horde.org Servers |
Type | Enhancement |
State | Rejected |
Priority | 2. Medium |
Owners | |
Requester | chuck (at) horde (dot) org |
Created | 04/22/2007 (6638 days ago) |
Due | |
Updated | 06/13/2008 (6220 days ago) |
Assigned | 10/30/2007 (6447 days ago) |
Resolved | 06/13/2008 (6220 days ago) |
Milestone | |
Patch | No |
Taken from
State ⇒ Rejected
State ⇒ Feedback
http://wiki.horde.org/Project/FutureSCM and the (likely) decision that
we aren't going to use SVN at all?
completely separate repositories.
comfortable with 6-digit version numbers that we'll get some day.
might get to 6-digit numbers anyway someday (okay, less likely since
we're only about 60% there with all horde commits so far, but that
means it'll take us a while to get there even with the whole
repository anyway). Not feeling comfortable with the numbers just
doesn't seem like a good reason to me.
completely separate repositories.
comfortable with 6-digit version numbers that we'll get some day.
should make sure first that Chora works fine with that. :)
example I moved some of the current ALPHA tags over:
http://svn.horde.org/repository/imp/tags/
In Chora:
http://svn.horde.org/imp/tags/IMP_4_2_ALPHA/
test them together? Or all FW_3? I don't want to have to check out
each app individually...
should make sure first that Chora works fine with that. :)
test them together? Or all FW_3? I don't want to have to check out
each app individually...
should make sure first that Chora works fine with that. :)
FW_3 would get all apps checked out too, correct?
can use tarballs, and the world of FW_3 apps isn't as huge as HEAD apps.
and think we should setup separate modules for each Horde app. Having
all tags and branches for all horde modules ever in branches/ and
tags/ looks really cluttered. I think it's worth not being able to
svn mv between horde modules for the benefit of a cleaner layout.
completely separate repositories. There is nothing hardcoded in
subversion about trunk/tags/etc - it's just a convention. We could to
a top-level list of modules with their own trunk, tags, branches dirs,
or we could do subdirs inside the /tags and /branches dirs just like
we have inside /trunk.
so that they are useable as-is. Then we could re-engineer HEAD to
simply work while expecting things to be side-by-side. That way we
get reasonable behavior for the (not so huge) set of FW_3 apps, and
can break BC for HEAD and have a nicer structure overall, period.
FW_3 would get all apps checked out too, correct?
After taking a look at the current SVN repository, I changed my mind
and think we should setup separate modules for each Horde app. Having
all tags and branches for all horde modules ever in branches/ and
tags/ looks really cluttered. I think it's worth not being able to svn
mv between horde modules for the benefit of a cleaner layout.
I think inline text-only diffs with a max message size would be
ideal. I agree about colored diffs and I also really hate systems
that send out commit messages over a megabyte. I think if we can do
it, something that sends a main body part with the log message and
chora links, and then inline attachments of type text/diff for up to
40k or so of changes, seems nice.
The svn way to do this is with externals, BUT: there is no way to
commit to everything at once using externals (per
http://svn.haxx.se/users/archive-2007-01/0955.shtml). The ideal
SVN. I had hopes that this could properly be dealt with in the meantime.
hooks/ dir of the repository and enabled.
we could move all FW_3 apps under the FW_3 horde in the repository, so
that they are useable as-is. Then we could re-engineer HEAD to simply
work while expecting things to be side-by-side. That way we get
reasonable behavior for the (not so huge) set of FW_3 apps, and can
break BC for HEAD and have a nicer structure overall, period.
In other news I've figured out what was wrong with the pre-commit hook
and it's about halfway fixed now.
anonsvn is available from http://svn.horde.org/repository/
developer svn is available from https://svn.horde.org/repository
(though right now only I have a password :)
chora is available from http://svn.horde.org/
On commit emails:
I think inline text-only diffs with a max message size would be ideal.
I agree about colored diffs and I also really hate systems that send
out commit messages over a megabyte. I think if we can do it,
something that sends a main body part with the log message and chora
links, and then inline attachments of type text/diff for up to 40k or
so of changes, seems nice.
On checking modules out inside other modules:
The svn way to do this is with externals, BUT: there is no way to
commit to everything at once using externals (per
http://svn.haxx.se/users/archive-2007-01/0955.shtml). The ideal
situation here is that we would have a tree of apps that didn't need
to be in the webroot, so we wouldn't need to put them inside each
other. Externals is a reasonable solution that would let us have a dev
tree and just commit to modules separately. Another option is
symlinks, which subversion can handle now - we could put links to the
apps inside the horde/ module, assuming they were now on the same
level as horde.
One side effect of having different developer and anonymous URLs
(https vs http) is that if we want to use externals on our own stuff,
it has to be different sets of externals properties for dev and anon.
On commit hooks:
I haven't done anything about a new commits list. The pre-commit hooks
are not working yet.
On access control:
Unless someone feels strongly I think we should try authenticated ==
write access at first.
rewriting rules for that. If it works, even better!
from cvs, with a single trunk and global tags and branches
directories? Or do we want one set of trunk/tags/branches per
project? Keeping the existing structure is simplest, and while it's a
lot easier to move stuff around with svn, it's not *completely* free
(still grows the repository a bit).
some pros and cons, especially technical ones. Separate projects
sounds nice, but since we copy/move code around between projects from
time to time, I can see having all in one (svn) project making more
sense.
But it's more important whether one of these setups makes it easier to
checkout one (horde) module inside another.
as attachments, or even colorized diffs as attachments (I have seen a
few that really were unified diff, just colored) but I wonder if it's
worth the message bloat. I have no strong opinion about this, but I'm
definitely happy with the way it works now.
by numbers) in log messages and have a post-commit script that posts
the log message and a link to the changeset to any bug mentioned in a
commit.
granting access to a few paths to a few developers. But see the
yellow box on that subversion page; I am currently inclined to agree
and to say that we don't really need to sandbox people off. If there
are social problems, then we probably shouldn't be letting people
commit code, period.
Though I have always considered the restrictions rather as a
prevention. Remember the PEAR developer tagging the whole PHP CVS
server a few years ago? This kind of stuff.
Beside that it still gave me that warm fuzzy feeling when adding new
developers I don't know well to cvs. But it's questionable if this is
worth it.
See
http://svnbook.red-bean.com/en/1.4/svn-book.html#svn.serverconfig.pathbasedauthz
I think it'll be trivial to port our "avail" file to authz. The
question is, do we need to and want to? I think I definitely want to
push for removing the distinction between "core" and "general"
developers. There is little difference, and it probably mostly
discourages people lumped into "general" (not so much now as it's just
2 people at the moment) from working on the website (hordeweb).
That gets rid of the need for most rules; after that it's just
granting access to a few paths to a few developers. But see the yellow
box on that subversion page; I am currently inclined to agree and to
say that we don't really need to sandbox people off. If there are
social problems, then we probably shouldn't be letting people commit
code, period.
guess we don't need the svn root folder for svn access and can use
some mod_rewrite or similar magic to correctly redirect requests to
either svn or chora. If not possible, svnweb.horde.org should work
too.
http://svn.horde.org -> Chora; http://svn.horde.org/repository ->
readonly dav_svn, https://svn.horde.org/repository - developer
dav_svn. We just couldn't then put something named "repository" into
the top level of svn. :) Suggestions for something other than
"repository" are fine by me too, but that's probably the way to go.
One more thing to consider: do we want to keep the structure ported
from cvs, with a single trunk and global tags and branches
directories? Or do we want one set of trunk/tags/branches per project?
Keeping the existing structure is simplest, and while it's a lot
easier to move stuff around with svn, it's not *completely* free
(still grows the repository a bit).
mailing list - do we want to maintain the Chora links, or go with
inline diffs, or ... ?)
files, and links to chora. We could also do inline unified diffs,
colorized diffs, or some combination thereof.
Another idea I'd like to implement is to recognize #\d+ (# followed by
numbers) in log messages and have a post-commit script that posts the
log message and a link to the changeset to any bug mentioned in a
commit.
web frontend, but we need to differentiate the URLs then)
guess we don't need the svn root folder for svn access and can use
some mod_rewrite or similar magic to correctly redirect requests to
either svn or chora. If not possible, svnweb.horde.org should work too.
mailing list - do we want to maintain the Chora links, or go with
inline diffs, or ... ?)
/usr/local/horde/svn/hooks/commit-php-syntax-check.pl, enabled in the
pre-commit script.
Assigned to
Taken from Chuck Hagenbuch
Taken from Ben Klang <ben@alkaloid.net>
Still to do:
* where do we want chora (assuming we prefer that in general for the
web frontend, but we need to differentiate the URLs then)
* do we want to require ssl for authenticated svn?
* port our access control hierarchy
* port our pre-commit checks (php-lint)
* port post-commit checks (or replace with another commit diff mailing
list - do we want to maintain the Chora links, or go with inline
diffs, or ... ?)
I think that's actually it.
Assigned to Chuck Hagenbuch
last week. It's no good for checking in new code, but we can use it
as a proof-of-concept and to tweak the pre-/post-commit scripts. I
would suggest we use the dav_svn mechanism instead of ssh like we do
today as it allows us greater control over ACLs and fewer OS tweaks
for supporting virtual users.
For future reference, it will take approximately 3 - 4 hours for the
scripts to run when we do the "live" conversion, so we'll need to
schedule the time to make sure no one needs to make commits while it's
running.
The repository lives at nazik:/usr/local/horde/svn
Assigned to Ben Klang <ben@alkaloid.net>
State ⇒ Assigned
(now a dns alias for nazik). We'll then need to make sure chora works
appropriately, access control works or is ported, and the pre/post
commit scripts run.
Priority ⇒ 2. Medium
State ⇒ Feedback
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Move to subversion for Horde code repository
Queue ⇒ Horde.org Servers
I know there are some concerns about organizing applications and
packages appropriately. I think that we might be able to use
svn:externals to address some or all of those concerns. There are some
useful notes about svn:externals here:
http://weierophinney.net/matthew/archives/132-svnexternals.html