Home | About | Sematext search-lucene.com search-hadoop.com
 Search Hadoop and all its subprojects:

Switch to Threaded View
Accumulo >> mail # dev >> GIT


That's fine. I don't really have a good understanding of the site
workflow. I know I commit code to our svn, then I update some local
working copy using the CMS tool, click stage, to stage my working copy
for preview, then I click publish to push my staged working copy to
yet another svn that shows itself on the website.

It seems to me that my CMS working copy could just as easily grab from
git in this workflow... or the CMS working copy could just grab from
the publication SVN instead of our project SVN...  but perhaps that's
just not implemented. Either way, making changes to the website seems
obtuse and I don't like it. If it's not affected by a switch to git, I
will continue to not like it, but at least we can table that for this
thread. :)

--
Christopher L Tubbs II
http://gravatar.com/ctubbsii
On Wed, Jun 5, 2013 at 12:48 PM, Billie Rinaldi
<[EMAIL PROTECTED]> wrote:
> As far as I can tell, the site will stay in SVN, and will be the only part
> of the SVN repo that remains writable after we switch to git.  (It has to
> stay in SVN because it relies on svnpubsub.)
>
> Billie
>
>
> On Wed, Jun 5, 2013 at 9:29 AM, Christopher <[EMAIL PROTECTED]> wrote:
>
>> Another thing to consider, since we mentioned contribs/subprojects, is
>> the site SCM. That's currently in SVN also.
>>
>> --
>> Christopher L Tubbs II
>> http://gravatar.com/ctubbsii
>>
>>
>> On Wed, Jun 5, 2013 at 12:23 PM, Josh Elser <[EMAIL PROTECTED]> wrote:
>> >
>> > On 6/5/13 10:51 AM, Keith Turner wrote:
>> >>>>
>> >>>> >>Can you give more detail about "history is easily mucked up"?  I am
>> >>>> >>curious
>> >>>> >>what constitutes a mucked up history and what sequence of steps lead
>> >>>> >> to
>> >>>> >>this?
>> >>>> >>
>> >>>> >>  http://dan.bravender.us/2011/**10/20/Why_cherry-picking_**
>> >>>
>> >>>
>> >>> > >should_not_be_part_of_a_**normal_git_workflow.html<
>> http://dan.bravender.us/2011/10/20/Why_cherry-picking_should_not_be_part_of_a_normal_git_workflow.html
>> >
>> >>
>> >>
>> >>
>> >> Thanks for the link, I do not think I could have easily found this via
>> >> google because I would not have know what to search for.  I have little
>> >> experience w/ git outside of small projects on github w/ one branch.
>>  Info
>> >> like this helps me make informed decisions.   Cherry picking vs merging
>> >> seems to be at the heart of what you are talking about, are there any
>> >> other
>> >> key concepts?
>> >>
>> > Cherry-pick and merging is definitely important. There are likely others,
>> > but none immediately come to mind.
>> >
>> >
>> >> Would probably be good to add this link, plus the other useful links
>> posed
>> >> in this thread, to the document you are working on.  I can make that
>> >> change
>> >> if you put it somewhere.
>> >>
>> >>
>> > Yep, that's currently the plan. I'll throw it up in SVN tonight. (how
>> meta)
>>