pharo-vcs / iceberg Goto Github PK
View Code? Open in Web Editor NEWIceberg is the main toolset for handling VCS in Pharo.
License: MIT License
Iceberg is the main toolset for handling VCS in Pharo.
License: MIT License
We might look at the hierarchy of MCDefinition for a guide to completeness.
Currently it does not re-read the directories, nor have another strategy to refresh the set of packages, the first list of packages is maintained (yet its children are refreshed).
Local git repos in iceberg-cache should keep being valid, either because they have been moved with the image or because we re-create the local clones from their remote counterparts.
Other git repos (with absolute file locations) will be expected to be in the same place, regardless of the image being moved.
Every created repository is remembered, so if you execute again IceRepository origin: '[email protected]:npasserini/pharo-git.git'
you will get the same repository again.
Also, each repository has a name that can be a simpler way to get access to it.
The default name is the same as the name of the github repository, so you can regain access to the recently created repository by evaluating: IceRepository named: 'pharo-git'
.
You can change the default name by doing: myRepo name: 'default'
.
IceClassChangeSet has the information but is not being shown in the UI.
Try this:
Metacello new
baseline: 'FileTree';
repository: 'github://npasserini/pharo-git:unexistent_branch';
onConflict: [:ex | ex allow];
load: 'Git'.
When you create a new tag inside a package, an MCDefinitionOperation is created, but with current formats it does not make sense to save it in github as this information is only contained inside classes.
If we require to ensure that a tag persists even without classes, we should change the file/tree format.
Or also manually.
It should create an Ice repository for the existing MCRepo.
In fact, maybe the IceRepo should already exist, so it does not make sense to create a new one.
Should allow to update the tool to the latest version:
Iceberg update
or to a specific version
Iceberg update: '0.0.2'
Iceberg update: #stable
Iceberg update: #bleedingEdge
And choose which options to enable in each case.
Maybe create a tool for branch management.
There are some types MCDefinition (specifically: MCOrganizationDefinition, which arises when you create or remove a Tag/Category) that contain no package information, but originally we obtained it from a package, we should refactor the way we compute changes to not loose the package association in the first moment.
This enhancement could become unnecessary if we change the underlying changes model.
Instead of one per package.
Changing branch or version of the repository could change the packages known in that repository, so we should update the package list.
Maybe we could put all classes at the same level and use different icons for them.
The first push to a locally created branch requires to set the upstream. We could default to upstream to the same branch or we could ask the user to make a decision.
It would be really nice to do a git mv to avoid loosing history.
And be coordinated with packageNamed:ifAbsent:
I am not sure that it is working.
We can reproduce it by changing pharo-git branch, and starting IceExamples exampleSynchronizer
exampleSynchronizer
| repository changeSet |
repository := Git new origin: '[email protected]:npasserini/pharo-git.git'.
changeSet := IceRepositoryChangeSet fromRepository: repository.
IceSynchronizer new
changeSet: changeSet;
openWithSpec.
I do not think it is a problem of the example, can happen in production code.
We should decide if we take the branch from the (pre)existing directory, use another directory or something smarter. Maybe we could let the user decide in each case.
On the other hand, if we removed the working copies from disk, this error would never happen.
Cloning a github repo in the tests is slow and also makes the tests impossible to run for someone not having access rights to the test repository.
This is because we create the tree looking at the packages that are already in the repository.
This is because we create the tree looking at the packages that are already in the repository.
Currently it fogets all elmenents which probably is not efficient.
Unloaded packages should not be shown in the changes tree (or note that they are unloaded).
Also they should not be taken into account when commited.
If I create a local repo in a preexisting location, I should validate that the previous repo
This is a lot of work.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.