Hi Carsten,

Am 08.09.2016 um 11:10 schrieb [email protected]:
> I fiddle a little around the use of mercurial repos.
> 
> For GIT the steps are:
> 
> fetch - clone the remote repo to DOWNLOADDIR,

The reason for GARCHIVEDIR is that stuff doesn’t get downloaded all over again 
every time
a spotless/package is done.

> but if there already a cloned repo in GARCHIVEDIR (/home/src) it will take 
> this and don't connect to the remote repository (target gitrepo:).

This seems wrong. It can clone from GARCHIVEDIR, but should then also pull from 
origin
and push back to GARCHIVEDIR.

> If no repo in GARCHIVEDIR, mgar will clone the remote repository to 
> DOWNLOADDIR.
> 
> makesums - don't create checksums, but copies the git repo from DONWLOADDIR 
> to GARCHIVEDIR, if it not exists already (target $(GARCHIVEDIR)/%:)

Hmm… maybe checksums should contain the GIT Revision.

> extract - creates an archive from repo in DONWLOADDIR and extracts the 
> archive in WORKDIR.

The Repo should be cloned and a new branch for patches in GAR should be created 
instead of
creating a new GIT Repository, this would make it easier to track patches. Also 
the cloned
repo in workdir/ could probably include a remote for garchive to permanently 
push patches
locally.

> This leads to some unexpected behavior if the repo in GARCHIVEDIR gets old. 
> So if you get some mysterious errors with fetch a GIT_REPOS it is a good idea 
> to delete the repo in GARCHIVEDIR.
> 
> Related to the trouble with old repositories in GARCHIVEDIR I am wondering if 
> it better not to use GARCHIVEDIR for GIT and Mercurial repositories?
> Or create an archive of the remote repo with name DISTNAME.tar.gz in 
> GARCHIVEDIR instead of copy of the repo? So you can see the version of the 
> source, sure only if the tag is not HEAD or tip.
> 
> Any thoughts?

Yes :-)


Best regards

 — Dago

--
"You don't become great by trying to be great, you become great by wanting to 
do something,
and then doing it so hard that you become great in the process." - xkcd #896

Attachment: signature.asc
Description: Message signed with OpenPGP using GPGMail

Reply via email to