Hi,
Am Feb 25, 2011 um 12:48 PM schrieb Dirk Reiners <[email protected]>:
>
> Hi Gerrit,
>
> On 02/24/2011 06:33 PM, Gerrit Voß wrote:
>>
>> It should not, if the cvs on sf is back and will work for a while
>> (does anybody know for how long)
>
> From what I can tell there are no plans to stop supporting CVS. They
> recommend
> not using it for new stuff, but I can't see an end-of-life date for CVS.
>
> The one thing that's not working right now is email from the SCM servers, but
> that's true for git, too. Not sure if that's a general problems or just not
> done
> yet.
From what I read it seems a temporary problem that affects all scms right
now, some scripts/modules missing.
>> I do not see the need to keep the git
>> mirror around for longer, so I will push the changes back to sf and
>> remove it. And if it is back for good, do we really want to move 1.x to
>> a different scm. At least I would like to avoid having 1 and 2 as
>> different branches in the same repository if there is no technical
>> element that forces us to do so.
>
> I would not have them as branches. SF supports mutliple repos, so we can have
> separate repos for 1 and 2. Permissions can only be set for all, so we'll
> have
> to depend on people being resonable, but I don't see giving a lot of people
> write access to the repo, especially with git.
Ah ok, missed that one.
>
>> I still use cygwin so no experience with 'native' window tools. We had
>> some students use it and the only thing I encountered was to force it
>> to respect and keep the newlines, but there is a config switch
>> for .git/config somewhere.
>
> That should be manageable.
The annoying part was that it had to be done locally and not as with
svn through server based properties.
>> IMHO we don't have to open the 'which dvcs' discussion, at least not
>> starting from the 'oh look there are others' level. If there is
>> a compelling technical reason to look into this fine, but otherwise I
>> would stick with git.
>
> Agreed, let's keep the holy wars on topic (i.e. scenegraphs). ;)
or at least stick to such classics as emacs vs vi ;)
>> Workflow is a different story. As said I prefer a linear stable
>> history so I prefer to rebase/cherry-pick my branches back to head and
>> commit them from there as linear continuations. Merging with the detours
>> staying visible is not my taste (yet)
>
> All for it. Github for the mess, SF for the clean, linear history where
> nobody
> ever commits buggy code. ;)
>
> When do you want to move?
I'm ready to go, so as soon as the repo is created (I'm not in the admin list so
I can't right now) on sf I can push the complete thing (except branches, do we
still need
them ?). But these can move over later if needed with no problems.
I actually would like to do it asap as I want to cleanout the sandbox and than
start merging
toolbox changes back to the main tree. With git i can keep the correct comitter
and
don't have to change the commit messages to attribute things correctly, little
less work ;)
bis denn
gerrit------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Opensg-core mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/opensg-core
