On 19 Dec 2004, at 03:50, Henri Yandell wrote:
Do we want to clean the sandbox up before an svn migration?
for the sake of component history (though a sandbox spring clean would
be attractive) it'd probably be better to move to subversion first.
- robert
Makes sense and I noticed that Tim's said that in the proposal so I
rescind the suggestion.
Hen
On Tue, 21 Dec 2004 19:27:42 +, robert burrell donkin
[EMAIL PROTECTED] wrote:
On 19 Dec 2004, at 03:50, Henri Yandell wrote:
Do we want to clean the sandbox up before an svn migration?
On 19 Dec 2004, at 03:50, Henri Yandell wrote:
Do we want to clean the sandbox up before an svn migration?
I'd also rather do it after svn migration.
Subversion, precisely, allows a better clean-up than cvs!
We'd jump on the first svn advantage as soon as we'd get in!
paul
Tim O'Brien [EMAIL PROTECTED] writes:
I know that most posters love Option A, however this makes it very
hard to check out the whole commons in one go. Which is what
e.g. the maven reactor builds would like to have (are they still
used?) or the commons builds, that need the site module.
You have
Tim O'Brien [EMAIL PROTECTED] writes:
Not following this one, this implies that ASF has one trunk. Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.
So, don't do it. Just copy your directory. into the release.
Subversion does not have the
Not very convenient to manage, though. Option B is better IMHO.
I don't understand this argument. One propset/propdel combo for
promotion or demotion is very manageable.
However, as other arguments in this thread have put forward, option A
has other benefits that don't have an alternative,
Noel J. Bergman [EMAIL PROTECTED] writes:
I also prefer the flatter layout:
jakarta/commons/tags/
/branches
/trunk
We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component. Someone
Hi Henning,
I replied to this on jakarta general the other day.
A major nit that I have to pick is the growing number of project
building with maven and the inability of _many_ maven plugins like the
changelog, dev or file activity lists to _use_ subversion. This is
many = 4. the 3 you listed,
Brett Porter [EMAIL PROTECTED] writes:
Hi Henning,
Hi Brett,
A major nit that I have to pick is the growing number of project
building with maven and the inability of _many_ maven plugins like the
changelog, dev or file activity lists to _use_ subversion. This is
many = 4. the 3 you listed,
Are these the versions released with 1.0.2? Also I feel uncomfortable
with works on one platform but not on another.
Yes. There is a windows specific bug in that release, so an updated
plugin will be made available for those publishing a site from a windows
machine.
This requires a manual
Henning P. Schmiedehausen wrote:
Checking out the whole trunk is not the norm.
Folks, this is not CVS. You are not bound to a rigid structure as with
CVS. But you _want_ to be able to check out multiple projects side by
side. Because some of the depend on each other (or on the commons-site
]
To: Jakarta Commons Developers List [EMAIL PROTECTED]
Sent: Sunday, December 19, 2004 7:14 AM
Subject: RE: Jakarta Commons Structure rehashed
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 18, 2004 11:12 PM
To: Jakarta Commons Developers List
Sounds like we really all agree that the structure of the Commons is
separate components. I think the big argument is that developers think
that somehow it will be difficult to check everything out if the svn is
organized in the same appropriate manner.
I'll argue that even in the cvs case, it
On Sun, 19 Dec 2004 11:32:53 -0500, Mark R. Diggory
[EMAIL PROTECTED] wrote:
Sounds like we really all agree that the structure of the Commons is
separate components. I think the big argument is that developers think
that somehow it will be difficult to check everything out if the svn is
Martin Cooper wrote:
That's fine and dandy if you're using an IDE such as Eclipse, but if
you don't use an IDE, it does make sense to just check out the whole
enchilada in one go. Or at least _I_ think it does. ;-)
--
Martin Cooper
You've got me thinking...
The more I study SVN (and I'm pretty
On Sun, 19 Dec 2004 13:46:09 -0500, Mark R. Diggory
[EMAIL PROTECTED] wrote:
Martin Cooper wrote:
That's fine and dandy if you're using an IDE such as Eclipse, but if
you don't use an IDE, it does make sense to just check out the whole
enchilada in one go. Or at least _I_ think it
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I think we're trying to find a compromise that satisfies
both. As long as someone can come up with a way to do the
equivalent of the '*' URL I mentioned above, I'd be happy
with A + that script / tool / method.
In message [EMAIL PROTECTED], Noel J. Bergman w
rites:
We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component. Someone
wanting to build all of Commons is not the norm.
I didn't want to reopen the issue. I was merely
On Sun, 19 Dec 2004 14:36:39 -0500, Tim O'Brien [EMAIL PROTECTED] wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I think we're trying to find a compromise that satisfies
both. As long as someone can come up with a way to do the
equivalent of the '*'
On Fri, 17 Dec 2004 18:10:12 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
And yet option A is going to be impossible (?) to check out as one whole blob.
It's not impossible, but it does require more time (because you end up
checking out all branches of all commons packages). Struts chose a
Just a note that the wiki proposal needs to consider the
authentication issues in jakarta-commons. ie) a different set of
user's for the sandbox directory as for the rest of it.
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
On Sun, 19 Dec 2004 19:23:15 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
Just a note that the wiki proposal needs to consider the
authentication issues in jakarta-commons. ie) a different set of
user's for the sandbox directory as for the rest of it.
From what I've seen in the SVN auth file,
On Mon, 2004-12-20 at 08:36, Tim O'Brien wrote:
-Original Message-
From: Martin Cooper [mailto:[EMAIL PROTECTED]
I think we're trying to find a compromise that satisfies
both. As long as someone can come up with a way to do the
equivalent of the '*' URL I mentioned above,
svn 1.1 (released 2004-09-29) supports symbolic links. Perhaps that
would resolve the issue by allowing us to (manually) build an
alternative directory containing just symbolic links to the trunk
directory of each subproject? Of course whenever a new subproject was
created, a symbolic link would
Henri Yandell wrote:
And yet option A is going to be impossible (?) to check out as one whole blob.
And what about this option ? Let say option C :
trunk/
jakarta/
commons/
digester/
beanutils/
tags/
branches/
Emmanuel Bourg
smime.p7s
Description: S/MIME
Option A + some sort of symlink structure sounds like a good idea. Does
subversion have some way of creating module aliases like what could be
done for CVS? This makes sense to be able to do this natively without
having to create symlinks. Maybe a feature request :)
Another reason for Option A
Another reason for Option A other than those already listed is that it
is consistent with what other projects have already started to adopt
(that I've seen), and that goes a long way to ease of use in itself.
That's my feeling as well. Even though we could use Option B, I'm more
comfortable
, this may make
sense, but commons components have wildly varied release cycles.
-Original Message-
From: Emmanuel Bourg [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 18, 2004 5:10 AM
To: Jakarta Commons Developers List
Subject: Re: Jakarta Commons Structure rehashed
Henri
-Original Message-
From: Henri Yandell [mailto:[EMAIL PROTECTED]
And yet option A is going to be impossible (?) to check out as one
whole
blob.
We could store two scripts (sh and bat) at the /jakarta/commons level
that would only grab the trunks of every component. So, I'd
On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
[EMAIL PROTECTED] wrote:
svn 1.1 (released 2004-09-29) supports symbolic links. Perhaps that
would resolve the issue by allowing us to (manually) build an
alternative directory containing just symbolic links to the trunk
directory of each
Tim O'Brien wrote:
Not following this one, this implies that ASF has one trunk.Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.
Err I thought Jakarta would have its own SVN repository, thus the trunk
would be Jakata-wide and not ASF-wide.
I thought Jakarta would have its own SVN repository
Not a chance.
--- Noel
smime.p7s
Description: S/MIME cryptographic signature
On Sat, 18 Dec 2004 21:22:12 +0100, Emmanuel Bourg [EMAIL PROTECTED] wrote:
Tim O'Brien wrote:
Not following this one, this implies that ASF has one trunk. Even
though copies are cheap I wouldn't want to create a copy of the entire
SVN tree for every release.
Err I thought Jakarta would
Use case for wanting to get all tags and branches for one component is
promotion from sandbox-proper, proper-jakarta, jakarta-TLP. Or the
opposite, which I hesitate to call demotion :)
Hen
On Sat, 18 Dec 2004 14:13:49 -0800, Martin Cooper [EMAIL PROTECTED] wrote:
On Sat, 18 Dec 2004 21:22:12
On Sat, 18 Dec 2004 20:34:47 -0500, Henri Yandell [EMAIL PROTECTED] wrote:
Use case for wanting to get all tags and branches for one component is
promotion from sandbox-proper, proper-jakarta, jakarta-TLP. Or the
opposite, which I hesitate to call demotion :)
Yah, good point. Then I guess I
Do we want to clean the sandbox up before an svn migration?
Hen
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
In message [EMAIL PROTECTED], Henri Yandell writes:
On Sun, 19 Dec 2004 00:00:20 +1300, Simon Kitching
[EMAIL PROTECTED] wrote:
svn 1.1 (released 2004-09-29) supports symbolic links. Perhaps that
would resolve the issue by allowing us to (manually) build an
alternative directory containing
I also prefer the flatter layout:
jakarta/commons/tags/
/branches
/trunk
We don't version Commons as a single component, and I don't know that we
want to force everyone to always take every single component. Someone
wanting to build all of Commons is not the
-Original Message-
From: Noel J. Bergman [mailto:[EMAIL PROTECTED]
Sent: Saturday, December 18, 2004 11:12 PM
To: Jakarta Commons Developers List
Subject: RE: Jakarta Commons Structure rehashed
I also prefer the flatter layout:
jakarta/commons/tags
I don't think we ever settled this question.
Which SVN structure are we interested in?
** Option A:
jakarta/
commons/
digester/
trunk/
tags/
branches/
beanutils/
trunk/
tags/
branches/
OR
** Option
Option B doesn't make a whole lot of sense to me. Most people are
interested in only a few commons projects so each having their own trunk,
tags, and branches makes sense. Struts lays out its subprojects using
Option A:
http://svn.apache.org/viewcvs.cgi/struts/
David
--- Tim O'Brien [EMAIL
Option A makes the projects look a lot more atomic, which seems like a
good idea when one contemplates what will be necessary when promoting
projects from the sandbox.
Kris
Tim O'Brien wrote:
I don't think we ever settled this question.
Which SVN structure are we interested in?
** Option A:
And yet option A is going to be impossible (?) to check out as one whole blob.
I wonder if there's any magic coming from the SVN guys that'll let us
do option B and yet provide a link of some kind to automatically be
able to check out all the trunks in one go.
Hen
On Fri, 17 Dec 2004 14:01:53
I tend to agree. I only work with a few commons components at a time.
And when using something like Eclipse one can checkout multiple projects
by selecting them all. its not that big a deal. Plus from a management
standpoint, the component is the atomic unit of the commons, organizing
around
44 matches
Mail list logo
