[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [PATCH 00/12] Plannings for secure-testing repository migration to git



Hi,
On Wed, Dec 27, 2017 at 11:32:53PM +0100, Salvatore Bonaccorso wrote:
[..snip..]
> have that already :). But I'm unahappy with my current versions, thus
> I have not sent those yet. Basically: I'm struggling with a proper
> replacement of such constructs:
> 
> cd /srv/security-tracker.debian.org/website/secure-testing/data && svn update && ../bin/update && svn commit -qm "automatic update" CVE && cd CVE && ../../bin/bts-update list

   cd /srv/security-tracker.debian.org/website/security-tracker/data && git pull origin master && ../bin/update && git commit -qm "automatic update" CVE && git push origin master && cd CVE && ../../bin/bts-update list

git commit might fail if there are no changes so we need to either guard
for that or use --allow-empty. git push might fail as well if there were
pushes in between. Since there are several commands that

    pull, modify, commit push

should we move this to a script that

    pulls, invokes the modification command, commits when there are
    changes, pushes. If that fails merges again && pushes again.

That won't save you from merge conflicts but that's the same with SVN a
assume?
Cheers,
 -- Guido

> > Should we create WiP/git-migration branches in the secure-testing and
> > security-tracker-service repos so others can send in pull requests?
> > 
> > We could rebase the branch in the secure-testing repo from time to time
> > so catch up with the changes in the svn repo.
> 
> Give me a bit of time to think about it. My intention was to not
> clutter now what we have on salsa as mirror and constantly push
> updates there. And once we go live, add the Debian group as allowed to
> push, and block the original svn repository.  I would like to avoid
> that people already start pushing to the git repository directly.
> 
> Or do you mean to still create the branches on the git repo on salsa
> (accessible readonly, so that people can contribute based on that,
> rather based on patch for pull requests? As said, I would like to not
> operate directly on the git repo until the switch  to not cause
> problems. Our live instance is currently still the svn repo).
> 
> I would expect we solve the open problems soonish enough so we can do
> the switch. That is:
> 
> 1/ desire of commit mailinglist
> 2/ how to do the updates with the sectracker role account specific to
> some files (e.g. automatic updates, data/CVE/list update, dsa
> canditate finding).
> 
> Thanks a lot for your contribution Guido!
> 
> Salvatore
> 


Reply to: