Slam Han
com
Ping, can I have some help to create Jira Project so that I can proceed to
release 1.0?
Otherwise, I can just keep it one more beta (4)
Thanks
-D
On Fri, Apr 12, 2013 at 11:58 PM, Anders Hammar wrote:
> I think it's ok to switch without releasing a beta first. I don't see any
> requirement
Christop
David M. Karr
Well Robert, it might not affect some, but it definitely affects others.
Take me for example. I don't have and won't install SVN on my main dev
machine. This mac is glacial at best, especially in a hot climate (30C
where I live at the moment), so I don't dev on it much. If the mojos of
interest to
Anyone can checkout or clone our codebase, patch it and choose not to
submit the patches back to the community - no matter which publicly
available VCS we use. I don't see that the choice of VCS should affect
that; the driver to submit patches to the official project is that you
don't want to keep
Yes ,I have these same concerns as Mark.
Of all the Maven related projects which have been moved from SVN to GIT I
haven't seen more patches then before. So I'm not sure if this will
increase the number of contributions.
Don't get me wrong: I do understand the advantages of GIT, but especiall
Xircles supports both git and svn repositories...
Now how much of the UI is behind where Grandcentral.cloudbees.com is,
that's a different question for Ben. But from a technical perspective we
can have git repos at codehaus... Just a question of how easy it is for us
to create them all... If Ben c
... and of course I mean Contegix instead of Canonical.
:)
Slight synaptic malfunction in the cognitive department, there.
2013/6/28 Lennart Jörelid
> I presume that most of us who have worked with distributed VCS's [Git or
> Mercurial, really] prefer them over SVN - just like we all felt wh
Can you generate the appropriate tags easily with filter-branch? That seems
to imply re-implementing the tag detection stuff in the bridge. Or am I
missing something?
On Fri, Jun 28, 2013 at 7:31 PM, Kristian Rosenvold
wrote:
> I usually find it best to make 1 git svn clone with all the repos and
I usually find it best to make 1 git svn clone with all the repos and
then just filter-branch the hell out of that -including rewriting of
roots, once for each repo.
In the case of mojo, once you get a script that works for one project
it should be possible to re-apply that script in an automated
I presume that most of us who have worked with distributed VCS's [Git or
Mercurial, really] prefer them over SVN - just like we all felt when moving
from CVS to SVN in the old days. It is simpler and considerably more agile
to work in a DCVS environment for distributed projects, just like the Linux
Christopher Hunt
Slam Han
com
Slam Han
upd
Not sure what your point is here.
The thing is Git makes it *very* easy to just mirror entire repository. So
even if we kept the canonical repositories somewhere at codehaus, that
wouldn't prevent people from cloning an just pushing those repos onto their
public clone @github or anywhere else.
(S
Absolutely agree with the canonical source thing! Any mirroring effort
should be considered a temporary thing, and a migration path once the tools
mature enough.
On Fri, Jun 28, 2013 at 4:55 PM, Mark Struberg wrote:
>
>
> There were some projects which moved to GIT.
>
> But after a short while t
Lonny Jacobson
There were some projects which moved to GIT.
But after a short while they are now all DEAD!
This has nothing to do with GIT itself (which I love), but with the missing
'ownership'.
It's totally easy on github to just fork a project and fix your bug there -
fully agree!
But what about merging
You have to subdivide the old monolithic SVN repo into the individual repos
that make sense, at the very least. Considering the sheer volume of it,
it'd be wise to either use, or create a method of
pre-analysing/transferring the entire SVN repo from day 1, and then extract
each git repo from that.
Hi,
>From my rememberings, not really.
GitHub has an "svn import" feature [1] but then you wouldn't be as easily
able to update your git copy.
Cheers
2013/6/28 Jochen Wiedmann
> Just asking: Does Github offer to provide an SVN mirror? Or is there any
> other way to have a mirror without too
Just asking: Does Github offer to provide an SVN mirror? Or is there any
other way to have a mirror without too much hazzle?
On Fri, Jun 28, 2013 at 9:50 AM, Fred Cooke wrote:
>
>
>> For GIT users there are several ways to work with SVN, so that's probably
>> why this isn't that urgent.
>>
>
>
Christopher Hunt
Lonny Jac
nicolas de loof
Stevo Slavic
Slam Han
com
>
> For GIT users there are several ways to work with SVN, so that's probably
> why this isn't that urgent.
>
That's not really a good reason not to, because:
- The SVN >> Git process isn't fast (because SVN is itself SLOW)
- Each converter has to find motivation to bother setting this up a
28 matches
Mail list logo
