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 PR
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:
ja
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 -0
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 t
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 woul
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 Crypto
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
comforta
group, 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 Common
> -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
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-wid
> 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 Jak
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
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 gue
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 c
> 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:
n" <[EMAIL PROTECTED]>
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
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 gre
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_
> -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 / met
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
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
> > equival
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
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 menti
"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.
Y
"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 ha
"Tim O'Brien" <[EMAIL PROTECTED]> writes:
>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 forsee the
>process as
Much easier. Create a "checkout" directory and add
beanutils http://<...>/jakarta/co
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, o
"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.
Craig McClanahan <[EMAIL PROTECTED]> writes:
>I'm +1 on Option A because of the "atomicity" argument -- branching
>Digester should not have any affect on Email, for example.
svn copy http:///jakarta/commons/trunk/digester \
http:///jakarta/commons/branches/digester-bar-branch
Where does
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, p
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
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
modul
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
43 matches
Mail list logo
